ghsa

random_compat versions prior to 2.0 are affected by a security vulnerability related to the insecure usage of Cryptographically Secure Pseudo-Random Number Generators (CSPRNG). The affected versions use openssl_random_pseudo_bytes(), which may result in insufficient entropy and compromise the security of generated random numbers.

Vulnerability in onelogin/php-saml versions prior to 2.10.0 allows signature Wrapping attacks which may result in a malicious user gaining unauthorized access to a system.

In order to verify Signatures on Logoutrequests and LogoutResponses we use the verifySignature of the class XMLSecurityKey from the xmlseclibs library. That method end up calling openssl_verify() depending on the signature algorithm used. The openssl_verify() function returns 1 when the signature was successfully verified, 0 if it failed to verify with the given key, and -1 in case an error occurs. PHP allows translating numerical values to boolean implicitly, with the following correspondences: - 0 equals false. - Non-zero equals true. This means that an implicit conversion to boolean of the values returned by openssl_verify() will convert an error state, signaled by the value -1, to a successful verification of the signature (represented by the boolean true). The LogoutRequest/LogoutResponse signature validator was performing an implicit conversion to boolean of the values returned by the verify() method, which subsequently will return the same output as openssl_verify() under mos...

Versions of nzo/url-encryptor-bundle prior to 5.0.1 and 4.3.2 are affected by a security vulnerability related to the lack of mandatory key and IV requirements. By default, the bundle uses the aes-256-ctr algorithm, which is susceptible to malleability attacks, potentially leading to Insecure Direct Object Reference (IDOR) vulnerabilities. Additionally, the reuse of keys enables users to decrypt and modify encrypted data if they can guess the plaintext of one ciphertext.

A remote code execution vulnerability has been found in the Swift Mailer library (swiftmailer/swiftmailer) recently. [See this advisory for details](http://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec-CVE-2016-10074-Vuln.html). If you are not using the default mail() transport, this particular problem does not affect you. Upgrading is of course still recommended!

It has been discovered that Neos is vulnerable to several XSS attacks. Through these vulnerabilities, an attacker could tamper with page rendering, redirect victims to a fake login page, or capture user credentials (such as cookies). With the potential backdoor upload an attacker could gain access to the server itself, to an extent mainly limited by the server setup. ### Reflected Cross-Site Scripting (SXSS) with authentication A Neos backend user with permission to modify content can insert JavaScript instructions into content elements. The browser will execute the script in "Print" preview mode. A Neos backend user who can modify his profile information ("Title", "First Name", "Last name", "Middle Name", "Other Name") can inject JavaScript instructions in those parameters. Once set up, an administrator who wants to edit this user account will execute the code. Both attack vectors require a valid Neos backend user account. ### Reflected Cross-Site Scripting (RXSS) without authentica...

It has been discovered that TYPO3 Neos is vulnerable to Privilege Escalation. Logged in editors could access, create and modify content nodes that exist in the workspace of other editors.

The PersistedUsernamePasswordProvider was prone to a information disclosure of account existance based on timing attacks as the hashing of passwords was only done in case an account was found. We changed the core so that the provider always does a password comparison in case credentials were submitted at all.

Due to reports it has been validated that internal workspaces in Neos are accessible without authentication. Some users assumed this is a planned feature but it is not. A workspace preview should be an additional feature with respective security measures in place. Note that this only allows reading of internal workspaces not writing. And for clarification, an internal workspace is a workspace that is non public and doesn't have an owner. Given that an internal workspace exists in your installation, it is possible to view a page in context of that workspace by opening a link in this format: https://domain/path/to/page.html@workspace-name The issue is quite problematic when exploited but at the same time slightly less impactful than it sounds. First of all there is no default internal workspace, so the issue affects only workspaces created by users. That also means the workspace-name, which will also always include a hash is individual to a project and an exploiter must get hold of t...

If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them. ### Am I affected? - Do you use Entity Security? if no, you are not affected. - You disabled the Doctrine Cache (Flow_Persistence_Doctrine)? If this is the case, you are not affected. - You use Entity Security in custom Flow or Neos applications. Read on. - If you only used Entity Security based on roles (i.e. role A was allowed to see entities, but role B was denied): In this case, you are not affected. - If you did more advanced stuff using Entity Security (like checking that a customer only sees his own orders; or a hotel only sees its own bookings), you very likely needed ...