Avisos recientes de vulnerabilidades procedentes de anuncios de fabricantes y noticias de seguridad. Estas alertas no cambian la puntuación de seguridad.
Según OpenNet, PHP tiene una vulnerabilidad de ejecución remota de código (CVE-2026-115560). No se especifican las versiones exactas afectadas. El mensaje no indica una versión corregida.
Qué hacer ahora: Comprueba si hay una actualización de PHP con la corrección e instálala.
scheb/two-factor-bundle bypass two-factor authentication with remember-me option
In versions prior to 3.26.0 and prior to 4.11.0 of the "scheb/two-factor-bundle" project, a security vulnerability allowed attackers to bypass two-factor authentication (2FA) using the remember_me cookie. When the remember_me checkbox was used during login, a "REMEMBERME" cookie was created. Upon redirection to the 2FA page, attackers could manipulate the SESSIONID key, granting access to the homepage "/" and gaining authentication without completing 2FA.
scheb/two-factor-bundle bypass two-factor authentication with unverified JWT trusted device token
Before version 3.7 the bundle is vulnerable to a [security issue in JWT](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/), which can be exploited by an attacker to generate trusted device cookies on their own, effectively by-passing two-factor authentication.
verbb/formie Server-Side Template Injection for variable-enabled settings
Formie is a Craft CMS plugin for creating forms. Prior to 2.1.6, users with access to a form's settings can include malicious Twig code into fields that support Twig. These might be the Submission Title or the Success Message. This code will then be executed upon creating a submission, or rendering the text. This has been fixed in Formie 2.1.6.
A vulnerability has been identified in the robrichards/xmlseclibs library, specifically related to XPath injection. The issue arises from inadequate filtering of user input before it is incorporated into XPath expressions.
The service offered by Pusher provides "private" channels with an authentication mechanism that restricts subscription access. The decision on allowing subscriptions to private channels is delegated to customers, who implement an authentication endpoint. End-users request a token from this endpoint to join a specific channel. The token is an HMAC signature of the end-user's connection ID (socket_id) and the desired channel.
The issue arises from a lack of validation in the libraries provided to customers. This vulnerability allows a malicious end-user to submit a malformed socket_id field, leading the customer to unknowingly sign a string. T
propel/propel1 SQL injection possible with limit() on MySQL
The limit() query method is susceptible to catastrophic SQL injection with MySQL.
For example, given a model User for a table users:
```
UserQuery::create()->limit('1;DROP TABLE users')->find();
```
This will drop the users table!
The cause appears to be a lack of integer casting of the limit input in either Criteria::setLimit() or in DBMySQL::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers.
This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection.
This affects all versions of Propel: 1.x, 2.x, and 3.
Propel2 SQL injection possible with limit() on MySQL
The limit() query method is susceptible to catastrophic SQL injection with MySQL.
For example, given a model User for a table users:
```
UserQuery::create()->limit('1;DROP TABLE users')->find();
```
This will drop the users table!
The cause appears to be a lack of integer casting of the limit input in either Propel\Runtime\ActiveQuery\Criteria::setLimit() or in Propel\Runtime\Adapter\Pdo\MysqlAdapter::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers.
This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection.
This affects
phpxmlrpc/extra XSS in class documenting_xmlrpc_server
Versions preceding 0.6.1 of the phpxmlrpc/extras project are susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability exists within the class documenting_xmlrpc_server when processing the GET methodName parameter.
Passbolt Api Tabnabbing when opening URI with menu "Open URI in a new tab"
### Description
A user could create and share a resource with a malicious URI. When the victim opens with menu “Open URI in a new tab” function, the malicious page has access to the window.opener object.
### Impact of issue
The newly opened malicious page can for example change the window.opener.location to redirect the user to a phishing page, or call a JavaScript function served by the AppJS on the user behalf for example to try to affect the integrity of the data.
### Fix
The code that opens a new window via window.open(); now open the tab with the noopener attribute.
Passbolt API Stored XSS on first/last name during setup
### Description
An administrator can craft a user with a malicious first name and last name, using a payload such as
```
<svg onload="confirm(document.domain)">'); ?></svg>
```
The user will then receive the invitation email and click on the setup link. The setup start page served by the server will fire the XSS.
### Impact of issue
An administrator could use this exploit to edit the setup start page for a given user, for example, trick the user into installing another extension. Even though the severity of this issue in itself is high, the likelihood is low because the exploit will be visible in clear by the user in the email notification,
Passbolt provides a way for system administrators to generate a PGP key for the server during installation. The wizard requests a username, an e-mail address and an optional comment. No escaping or verification is done by Passbolt, effectively allowing a user to inject bash code.
The impact is very high, but the probability is very low given that this vulnerability can only be exploited during Passbolt’s installation stage.
Passbolt uses three cookies: a session cookie, a CSRF protection cookie and a cookie to keep track of the multiple-factor authentication process.
Both the session cookie and the mfa cookie are properly set HTTP-only to prevent an attacker from retrieving the content of those cookies if they managed to exploit an XSS.
The /auth/verify.json endpoint returns a JSON that, among other things, contains the cookies sent in the request. (similar to the TRACE HTTP method)
An attacker who manages to leverage an XSS vulnerability could retrieve the session cookies of a legitimate user, effectively granting them the ability to retrieve information (su
Passbolt sends e-mail to users to warn them about different type of events such as the creation, modification or deletion of a password. Those e-mails may contain user-specified input, such as a password’s title or description.
Passbolt does not escape the user’s input properly, resulting in the user being able to inject HTML code in an e-mail.
An authenticated attacker could share a password containing an img HTML tag in its description with an other user to obtain information about their mail user-agent.
This vulnerability has a very low impact. Most MUA do not embed remote images to protect their users’ privacy.
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.
onelogin/php-saml Improper signature validation on LogoutRequest/LogoutResponse.
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
nzo/url-encryptor-bundle Insecure default secret key and IV allowing anyone to decrypt values
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!