MuraCMS through 10.1.10 contains a CSRF vulnerability in the bundle creation functionality (csettings.cfc createBundle method) that allows unauthenticated attackers to force administrators to create and save site bundles containing sensitive data to publicly accessible directories. This vulnerability enables complete data exfiltration including user accounts, password hashes, form submissions, email lists, plugins, and site content without administrator knowledge. This CSRF vulnerability enables complete data exfiltration from MuraCMS installations without requiring authentication. Attackers can force administrators to unknowingly create site bundles containing sensitive data, which are saved to publicly accessible web directories. The attack executes silently, leaving administrators unaware that confidential information has been compromised and is available for unauthorized download.
The Trash Restore CSRF vulnerability in MuraCMS through 10.1.10 allows attackers to restore deleted content from the trash to unauthorized locations through CSRF. The vulnerable cTrash.restore function lacks CSRF token validation, enabling malicious websites to forge requests that restore content to arbitrary parent locations when an authenticated administrator visits a crafted webpage. Successful exploitation of the Trash Restore CSRF vulnerability results in unauthorized restoration of deleted content to potentially inappropriate or malicious locations within the MuraCMS website structure. When an authenticated administrator visits a malicious webpage containing the CSRF exploit, their browser automatically submits a hidden form that restores specified content from the trash to a location determined by the attacker through the parentid parameter. This can lead to restoration of previously deleted malicious content, placement of sensitive documents in public areas, manipulation of website navigation structure, or restoration of outdated content that was intentionally removed for security or compliance reasons.
The update address CSRF vulnerability in MuraCMS through 10.1.10 allows attackers to manipulate user address information through CSRF. The vulnerable cUsers.updateAddress function lacks CSRF token validation, enabling malicious websites to forge requests that add, modify, or delete user addresses when an authenticated administrator visits a crafted webpage. Successful exploitation of the update address CSRF vulnerability results in unauthorized manipulation of user address information within the MuraCMS system, potentially compromising user data integrity and organizational communications. When an authenticated administrator visits a malicious webpage containing the CSRF exploit, their browser automatically submits a hidden form that can add malicious addresses with attacker-controlled email addresses and phone numbers, update existing addresses to redirect communications to attacker-controlled locations or deleted legitimate address records to disrupt business operations. This can lead to misdirected sensitive communications, compromise of user privacy through injection of attacker contact information, disruption of legitimate business correspondence, and potential social engineering attacks via the corrupted address data.
MuraCMS through 10.1.10 contains a CSRF vulnerability that allows attackers to permanently destroy all deleted content stored in the trash system through a simple CSRF attack. The vulnerable cTrash.empty function lacks CSRF token validation, enabling malicious websites to forge requests that irreversibly delete all trashed content when an authenticated administrator visits a crated webpage. Successful exploitation of the CSRF vulnerability results in potentially catastrophic data loss within the MuraCMS system. When an authenticated administrator visits a malicious page containing the CSRF exploit, their browser automatically submits a hidden form that permanently empties the entire trash system without any validation, confirmation dialog, or user consent.
Glances is an open-source system cross-platform monitoring tool. The GHSA-gh4x fix (commit 5d3de60) addressed unauthenticated configuration secrets exposure on the `/api/v4/config` endpoints by introducing `as_dict_secure()` redaction. However, the `/api/v4/args` and `/api/v4/args/{item}` endpoints were not addressed by this fix. These endpoints return the complete command-line arguments namespace via `vars(self.args)`, which includes the password hash (salt + pbkdf2_hmac), SNMP community strings, SNMP authentication keys, and the configuration file path. When Glances runs without `--password` (the default), these endpoints are accessible without any authentication. Version 4.5.2 provides a more complete fix.
In Juju from version 3.0.0 through 3.6.18, when a secret owner grants permissions to a secret to a grantee, the secret owner relies exclusively on a predictable XID of the secret to verify ownership. This allows a malicious grantee which can request secrets to predict past secrets granted by the same secret owner to different grantees, allowing them to use the resources granted by those past secrets. Successful exploitation relies on a very specific configuration, specific data semantic, and the administrator having the need to deploy at least two different applications, one of them controlled by the attacker.
Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in OpenText™ ZENworks Service Desk allows Cross-Site Scripting (XSS). The vulnerability could allow an attacker to execute arbitrary JavaScript leading to unauthorized actions on behalf of the user.This issue affects ZENworks Service Desk: 25.2, 25.3.
A race condition in the secrets management subsystem of Juju versions 3.0.0 through 3.6.18 allows an authenticated unit agent to claim ownership of a newly initialized secret. Between generating a Juju Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.
An authorization bypass vulnerability in the Vault secrets back-end implementation of Juju versions 3.1.6 through 3.6.18 allows an authenticated unit agent to perform unauthorized updates to secret revisions. With sufficient information, an attacker can poison any existing secret revision within the scope of that Vault secret back-end.
In Juju from version 3.0.0 through 3.6.18, the authorization of the "secret-set" tool is not performed correctly, which allows a grantee to update the secret content, and can lead to reading or updating other secrets. When the "secret-set" tool logs an error in an exploitation attempt, the secret is still updated contrary to expectations, and the new value is visible to both the owner and the grantee.