PatchFirst · Latest vulnerabilities
Vulnerabilities published for PHP in the last 30 days: 222. Listed in the KEV catalogue: 2.
Fresh vulnerability reports from vendor announcements and security news. These warnings do not change the security rating.
According to OpenNet, PHP has a remote code execution vulnerability (CVE-2026-115560). The exact affected versions are unspecified. The report does not name a fixed version.
What to do now: Check whether a PHP update with the fix is available and install it.
CVE-2026-115560
Vulnerabilities: 7239
Sylius 1.0.0 to 1.0.16, 1.1.0 to 1.1.8, 1.2.0 to 1.2.1 versions of AdminBundle and ResourceBundle are affected by this security issue. This issue has been fixed in Sylius 1.0.17, 1.1.9 and 1.2.2. Development branch for 1.3 release has also been fixed. ### Description The following actions in the admin panel did not require a CSRF token: - marking order’s payment as completed - marking order’s payment as refunded - marking product review as accepted - marking product review as rejected ### Resolution The issue is fixed by adding a required CSRF token to those actions. We also fixed `ResourceController`‘s `applyStateMachineTransitionAct
Prior to 5.2.1, the sendmail transport (`Swift_Transport_SendmailTransport`) was vulnerable to an arbitrary shell execution if the "From" header came from a non-trusted source and no "Return-Path" is configured. This has been fixed in 5.2.1. If you are using sendmail as a transport, you are encouraged to upgrade as soon as possible.
The vulnerability pertains to the usage of an insecure random number generator (RNG) in the "stormpath-sdk-php" library. Specifically, the issue is present in the generation of UUID (Universally Unique Identifier) version 4 within the codebase.
ScnSocialAuth version 1.15.2 has been released and includes a security for this vulnerability. Fix has been applied in https://github.com/SocalNick/ScnSocialAuth/commit/4a00966c41bc37251586d007564c5c891eba3700 ### Affected versions All versions below 1.15.2 are affected. dev-master is fixed starting from https://github.com/SocalNick/ScnSocialAuth/commit/4a00966c41bc37251586d007564c5c891eba3700 ### Exploits Because of missing escaping of the URL param redirect a XSS attack is possible. For example: Setting the redirect param to `"><a%20href="http://github.com">GitHub.com</a><inpu%20type="hidden"%20"` would result in a link added to the login
### Background SimpleSAMLphp 1.17 includes a preview of the new user interface to be included in the future version 2.0. This new user interface can be enabled by setting the usenewui configuration option to true, and it includes a new admin interface in a module called admin, which can be disabled. ### Description The new admin interface includes a way to view information about the host where SimpleSAMLphp is installed, by means of the phpinfo() PHP function. An endpoint that exposes the output of that function is included in the admin module for easier debugging. The aforementioned endpoint had no checks for administrator privileges. This
### Background SimpleSAMLphp uses metadata to determine how to interact with other SAML entities. This metadata includes what’s called endpoints, which are URLs belonging to that entity where SAML messages can be sent. These URLs are used directly by SimpleSAMLphp when a message is sent, either via an HTTP redirection or by automatically posting a form to them. ### Description When sending a SAML message to another entity, SimpleSAMLphp will use the URL of the appropriate endpoint to redirect the user’s browser to it, or craft a form that will be automatically posted to it, depending on the SAML binding used. The URL that’s target of the mes
Smarty is a template engine for PHP, facilitating the separation of presentation (HTML/CSS) from application logic. In affected versions template authors could inject php code by choosing a malicious file name for an extends-tag. Sites that cannot fully trust template authors should update asap. All users are advised to update. There is no patch for users on the v3 branch. There are no known workarounds for this vulnerability.
### Background In order to implement support for the SAML Enhanced Client or Proxy profile, the credentials obtained for authentication were stored in the state in order to pass them to the relevant routines. This, however, led to the credentials being recorded in the user’s session, which can be stored in permanent storage such as the local file system or a remote memcache or database server. ### Description When an authentication request is received via the ECP profile, the username and password obtained this way were saved to the state array, which is used to pass relevant data to different routines that may need it. This is not a problem
### Background Several scripts part of SimpleSAMLphp display a web page with links obtained from the request parameters. This allows us to enhance usability, as the users are presented with links they can follow after completing a certain action, like logging out. ### Description The following scripts were not checking the URLs obtained via the HTTP request before displaying them as the target of links that the user may click on: - www/logout.php - modules/core/www/no_cookie.php The issue allowed attackers to display links targeting a malicious website inside a trusted site running SimpleSAMLphp, due to the lack of security checks involving
There is a low level potential SQL injection vulnerability in the silverstripe/subsites module has been identified and fixed in version 2.1.1.
There is a vulnerability in silverstripe/taxonomy module that allows SQL injection. This affected controller (`TaxonomyDirectoryController`) is disabled by default and must be enabled by a developer for the exploit to be possible.
The [userforms module](https://github.com/silverstripe/silverstripe-userforms) allows CMS administrators to create public facing forms with file upload abilities. These files are uploaded into a predictable public path on the website, unless configured otherwise by the CMS administrator setting up the form. While the name of the uploaded file itself is not predictable, certain actions taken by CMS authors could expose it. For example, submission notification emails contain a link to the file without authorisation checks. In 3.0.0 this field is disabled by default, but re-enabled upon installation of the [secure assets module](https://github.
A cross-site scripting (XSS) vulnerability in the Edit function of Formwork before 1.13.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Content field.
The GraphQL controller lacked any CSRF protection, meaning authenticated users could be forced or tricked into visiting a URL that would send a GET request to the affected web server that could mutate or destroy data without the user knowing.
A potential SQL injection vulnerability was identified by using the silverstripe/postgresql database adapter. While unlikely to be exploitable, we have patched silverstripe/framework to ensure that table names are safely escaped before being passed to database adapters or user code.
A possible denial of service attack vector has been identified in the dev/build system controller. dev/build now has its own URL token, similar to flushtoken, to ensure users are authenticated when running dev/build outside of dev environments.
When running SilverStripe 3.7 or 4.x in dev mode with the mysqli database driver, there is a potential to disclose the connection details. We have blacklisted the sensitive parts of the connection information from being included in dev mode stack traces when database errors occur.
Some potentially dangerous file types exist in File.allowed_extensions which could allow a malicious CMS user to upload files that then get executed in the security context of the website. We have removed the ability to upload .css, .js, .potm, .dotm, .xltm and .jar files in the default configuration. Since allowed_extensions are synced to webserver configuration (in assets/.htaccess) automatically, this will also deny access to any existing uploads with these extensions. Review our security guidelines for the Common Web Platform and the File Security guide for SilverStripe 4 to find out how to add or remove extensions.
There is a user ID enumeration vulnerability in our brute force error messages. - Users that don't exist in will never get a locked out message - Users that do exist, will get a locked out message This means an attacker can infer or confirm user details that exist in the member table. This issue has been resolved by ensuring that login attempt logging and lockout process works equivalently for non-existent users as it does for existant users. This is a regression of [SS-2017-002](https://www.silverstripe.org/download/security-releases/ss-2017-002).
Under some circumstances a form may populate a PasswordField with submitted data, reflecting submitted data back to a user. The user will only see their own submissions for password data, which is not considered best practice. We are not aware of data leaks to other users, devices or sessions.
Check your installed stack and versions against the current vulnerability feeds.