#php

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...

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...

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 ...

It has been discovered that Flow 3.0.0 allows arbitrary file uploads, inlcuding server-side scripts, posing the risk of attacks. If those scripts are executed by the server when accessed through their public URL, anything not blocked through other means is possible (information disclosure, placement of backdoors, data removal, …). Note: The upload of files is only possible if the application built on Flow provides means to do so, and whether or not the upload of files poses a risk is dependent on the system setup. If uploaded script files are not executed by the server, there is no risk. In versions prior to 3.0.0 the upload of files with the extension php was blocked. In Flow 2.3.0 to 2.3.6 a potential XML External Entity processing vulnerability has been discovered in the MediaTypeConverter.

Several widely-used JSON Web Token (JWT) libraries, including node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, and jsjwt, are affected by critical vulnerabilities that could allow attackers to bypass the verification step when using asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512).

Magento Commerce 1.14.4.0 and Open Source 1.9.4.0 have been enhanced with critical security updates to address multiple vulnerabilities, including remote code execution (RCE), cross-site scripting (XSS), cross-site request forgery (CSRF), and more. The following issues have been identified and remediated: - PRODSECBUG-1589: Stops Brute Force Requests via basic RSS authentication - MAG-23: M1 Credit Card Storage Capability - PRODSECBUG-2149: Authenticated RCE using customer import - PRODSECBUG-2159: API Based RCE Vulnerability - PRODSECBUG-2156: RCE Via Unauthorized Upload - PRODSECBUG-2155: Authenticated RCE using dataflow - PRODSECBUG-2053: Prevents XSS in Newsletter Template - PRODSECBUG-2142: XSS in CMS Preview - PRODSECBUG-1860: Admin Account XSS Attack Cessation via Filename - PRODSECBUG-2119: EE Patch to include names in templates - PRODSECBUG-2129: XSS in Google Analytics Vulnerability - PRODSECBUG-2019: Merchant Wishlist Security Strengthening - PRODSECBUG-2104: Send to a Frie...

Magento Commerce 1.14.3.9 and Open Source 1.9.3.9 bring essential security enhancements with Patch SUPEE-10752. These updates address various vulnerabilities, including authenticated Admin user remote code execution (RCE), cross-site request forgery (CSRF), and more. Key Security Improvements: - APPSEC-2001: Authenticated Remote Code Execution (RCE) using custom layout XML - APPSEC-2015: Authenticated Remote Code Execution (RCE) through the Create New Order feature (Commerce only) - APPSEC-2042: PHP Object Injection and RCE in the Magento admin panel (Commerce Target Rule module) - APPSEC-2029: PHP Object Injection and Remote Code Execution (RCE) in the Admin panel (Commerce) - APPSEC-2007: Authenticated SQL Injection when saving a category - APPSEC-2027: CSRF is possible against Web sites, Stores, and Store Views - APPSEC-1882: The cron.php file can leak database credentials - APPSEC-2006: Stored cross-site scripting (XSS) through the Enterprise Logging extension - APPSEC-2005: Pers...

### Impact Those using SQL Server with Laravel and allowing user input to be passed directly to the limit and offset functions are vulnerable to SQL injection. Other database drivers such as MySQL and Postgres are not affected by this vulnerability. ### Patches This problem has been patched on Laravel versions 6.20.26, 7.30.5, and 8.40.0. ### Workarounds You may workaround this vulnerability by ensuring that only integers are passed to the limit and offset functions, as well as the skip and take functions.