| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Missing authorization in WebUI in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Information leak in ServiceWorker in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Medplum is a developer platform that enables development of healthcare apps. Prior to version 5.1.6, the external identity provider callback at GET /auth/external accepts attacker-controlled redirect URIs that only need to start with a registered client redirect URI, rather than matching exactly. After a successful external IdP login, the server appends Medplum login and code values to that attacker-supplied URL and issues a redirect. Because the external login request state is serialized as raw JSON and later trusted by the callback, an attacker who can tamper with state.redirectUri can cause Medplum to redirect authorization artifacts to an attacker-controlled endpoint. When the registered redirect URI is a bare origin or another prefix that can be extended into a different hostname, this becomes a cross-origin authorization code leak. This issue has been patched in version 5.1.6. |
| Incorrect authorization in GPU in Google Chrome on on Mac prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| CommServe contained a cryptographic signature verification issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update CommServe and Web Server. |
| Impact:
When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination.
This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP.
Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin.
This was introduced in undici 7.23.0 via PR #4385 and affects all versions through 8.1.0.
Patches:
Upgrade to undici v7.26.0 or v8.2.0.
Workarounds:
Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins. |
| The web
interface of the affected
device relies on the HTTP referrer header as part of
request validation. Requests containing empty Referer value, or omitting
the Referer header entirely, may be accepted and processed due to insufficient
validation logic.
Successful exploitation may allow an adjacent attacker with access to the web management
interface to obtain device configuration details and other sensitive
information. |
| Origin validation error in .NET allows an unauthorized attacker to disclose information over a network. |
| A flaw was found in odh-dashboard, the web console component of Red Hat OpenShift AI (RHOAI). Due to incorrect network binding, a malicious actor within the cluster can bypass authentication and impersonate any user by providing an arbitrary access token. This allows an attacker to gain unauthorized access to the Kubernetes API, potentially leading to arbitrary code execution, privilege escalation, or information disclosure. |
| YesWiki is a wiki system written in PHP. From version 4.6.2 to before version 4.6.6, HttpSignatureService::verifySignature() checks the result of PHP's openssl_verify() with a loose boolean negation - if (!openssl_verify(...)) { throw ... }. PHP's openssl_verify has four possible return values: 1, 0, -1, and "false". The -1 row is the bypass: PHP's truthiness rules make -1 a truthy value, so !(-1) === false, the throw is skipped, and the controller proceeds to processActivity(). Any condition that makes OpenSSL's EVP_VerifyFinal() return -1 triggers the bypass. The reachable consequence is the controller silently treats a failed verification as success and processes the attacker's payload. This issue has been patched in version 4.6.6. |
| When using the Direct XIP
update strategy, the main application image starts other cores (i.e. radio
core), based on the currently active slot without additional verification. The
MCUboot in the bare (upstream) configuration assumes that if there is at least
a single slot for each image available, the system is bootable and continues
the boot process. This may lead to a situation when MCUboot picks different
slot for different images (i.e. (a) for the main application and (b) for the
radio image), boots the main application (from slot (a)) that afterwards starts
the radio image by providing an address of the unauthenticated slot ((a)
instead of (b)). |
| SAP Approuter does not consistently enforce integrity verification on certain session-related request headers under specific conditions. An attacker with low privileges could send a specially crafted request that bypasses the integrity check and loads another user's session context. Successful exploitation requires the attacker to have previously observed matching session values out-of-band, which makes the attack complex to execute. This could result in a high impact on confidentiality and a low impact on integrity. There is no impact on availability. |
| Origin validation error in Microsoft Teams for Android allows an authorized attacker to disclose information over a network. |
| MojoX::Authentication versions before 0.006 for Perl allow SAML authentication bypass because parse_assertion builds Net::SAML2::Binding::POST without a trust anchor.
parse_assertion in MojoX::Authentication::Model::SAML2 calls Net::SAML2::Binding::POST->new with no cacert, cert_text or anchors argument, then passes the returned XML to Net::SAML2::Protocol::Assertion->new_from_xml with the IdP signing certificate as cacert. In Net::SAML2 before 0.86 that certificate guards only encrypted assertions, so the signature on an unencrypted assertion is checked against the certificate the response itself carries.
An attacker starts a SAML login, then posts a response signed with a certificate of their own. The audience, InResponseTo and timestamp checks that follow are all satisfiable by the attacker, so the response authenticates any NameID it carries. |
| A flaw was found in operator-sdk-builder. The containers-policy.json configuration file defaults to insecureAcceptAnything for container image registries that are not explicitly listed. This default setting causes signature verification to be entirely skipped for images pulled from these unlisted registries, which could allow for the use of untrusted or malicious container images. |
| Improper verification of cryptographic signature in Copilot Studio allows an unauthorized attacker to elevate privileges over a network. |
| Multiple vulnerabilities in the Secure/Multipurpose Internet Mail Extensions (S/MIME) decryption functionality of Cisco Secure Email could allow an unauthenticated, remote attacker to recover plain text from encrypted email messages.
These vulnerabilities are due to insufficient validation of message integrity. An attacker could exploit these vulnerabilities by using a machine-in-the-middle technique to intercept and modify traffic between email gateways. A successful exploit could allow the attacker to obtain plaintext content from the encrypted communication. |
| RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an authorized user key, checking the key type and modulus but omitting the exponent. Because signature verification uses the client-supplied key, an attacker knowing an authorized RSA modulus can supply a key with exponent one, forge a valid signature, and open an SSH command channel as the target user without the private key.This issue affects only 7.x branch was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable) |
| MOOS-IvP uFldShoreBroker through 24.8.1 fails to verify node ping authenticity before creating outbound bridge routes. Attackers can publish NODE_BROKER_PING messages with crafted HostRecord data to redirect bridged variables to attacker-controlled addresses. |
| MOOS-IvP uFldNodeComms through 24.8.1 trusts the source node identity from the message body rather than validating it from the connection source. Attackers can craft NODE_MESSAGE packets with spoofed source identities to impersonate other nodes and post arbitrary variable notifications without validation. |
