A supply chain attack targeting Axios npm package versions 1.14.1 and 0.30.4 introduced a malicious transitive dependency (plain-crypto-js@4.2.1) that executed during installation. The attack deploys cross-platform payloads across Linux, Windows, and macOS through a consistent pattern: Node.js spawns OS-native shells to retrieve and execute remote payloads in detached or hidden contexts. Linux victims receive a Python-based RAT, Windows systems get a PowerShell backdoor with registry persistence, and macOS hosts are compromised with a Mach-O binary backdoor. All variants beacon to the same C2 infrastructure, performing host fingerprinting, process enumeration, filesystem reconnaissance, and arbitrary code execution. The malicious activity is reliably detected through behavioral signatures focusing on unusual Node.js process ancestry and remote payload retrieval rather than static indicators.
## Summary
While testing the *GitHubProvider* OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.
## Technical Details
An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the *GitHubProvider* OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.
Although this issue was verified in practice only for the *GitHubProvider*, a review of the source code, specifically the `OAuthProxy._handle_idp_callback` [function](https://github.com/jlowin/fastmcp/blob/ee5f465a82350e1c5a56c4a2b47cfdc4cd736e76/src/fastmcp/server/auth/oauth_proxy.py#L1762), shows that the IdP callback handler does not verify whether the browser sending the `state` and `code` has previously consented to connecting the client to the server. As long as a valid `state` and `code` pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new `code` and the corresponding `state`, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.
Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.
## Steps to reproduce
1. Set up an MCP server using the *GitHubProvider* integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.
In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.
## Recommendation
To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the [mitigations section](https://mcp.mintlify.app/specification/2025-11-25/basic/security_best_practices#mitigation) for this vulnerability in the MCP specification.
The async local filesystem memory tool in the Anthropic Python SDK validated that model-supplied paths resolved inside the sandboxed memory directory, but then returned the unresolved path for subsequent file operations. A local attacker able to write to the memory directory could retarget a symlink between validation and use, causing reads or writes to escape the sandbox. The synchronous memory tool implementation was not affected.
Users on the affected versions are advised to update to the latest version.
Claude SDK for Python thanks [hackerone.com/kasthelord](https://hackerone.com/kasthelord) for reporting this issue!
The local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected.
Users on the affected versions are advised to update to the latest version.
Claude SDK for Python thanks [`lucasfutures`](https://hackerone.com/lucasfutures) on HackerOne for the report.
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to version 46.0.6, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for *.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com. This issue has been patched in version 46.0.6.
# Authenticated Local File Inclusion (LFI) via selectobject.php leading to sensitive data disclosure
## Target
Dolibarr Core (Tested on version 22.0.4)
## Summary
A Local File Inclusion (LFI) vulnerability has been discovered in the core AJAX endpoint `/core/ajax/selectobject.php`. By manipulating the `objectdesc` parameter and exploiting a fail-open logic flaw in the core access control function `restrictedArea()`, an authenticated user with no specific privileges can read the contents of arbitrary non-PHP files on the server (such as `.env`, `.htaccess`, configuration backups, or logs…).
## Vulnerability Details
The vulnerability is caused by a critical design flaw in `/core/ajax/selectobject.php` where dynamic file inclusion occurs **before** any access control checks are performed, combined with a fail-open logic in the core ACL function.
- **Arbitrary File Inclusion BEFORE Authorization:** The endpoint parses the `objectdesc` parameter into a `$classpath`. If `fetchObjectByElement` fails (e.g., by providing a fake class like `A:conf/.htaccess:0`), the application falls back to `dol_include_once($classpath)` at **line 71**. At this point, the arbitrary file is included and its content is dumped into the HTTP response buffer. This happens *before* the application checks any user permissions.
- **Access Control Bypass (Fail-Open):** At **line 102**, the application finally attempts to verify permissions by calling `restrictedArea()`. Because the object creation failed, the `$features` parameter sent to `restrictedArea()` is empty (`''`). Inside `security.lib.php`, if the `$features` parameter is empty, the access check block is completely skipped, leaving the `$readok` variable at `1`. Because of this secondary flaw, the script finishes cleanly with an HTTP 200 OK instead of throwing a 403 error.
This allows any authenticated user to bypass ACLs and include files. While PHP files cause a fatal error before their code is displayed, the contents of any text-based file (like `.htaccess`, `.env`, `.json`, `.sql`) are dumped into the HTTP response before the application crashes.
## Steps to Reproduce
- Log in to the Dolibarr instance with any user account (no specific permissions required).
- Intercept or manually forge a GET request to the following endpoint:
```
GET /core/ajax/selectobject.php?outjson=0&htmlname=x&objectdesc=A:conf/.htaccess:0
```
- Observe the HTTP response. The contents of the `conf/.htaccess` file will be reflected in the response body right before the PHP Fatal Error message.
- *(Optional)* Run the attached Python PoC to automate the extraction:
```
python3 poc.py --url http://target.com --username '<username>' --password '<password>' --file conf/.htaccess
```
## Impact
An attacker with minimal access to the CRM can exfiltrate sensitive files from the server. This can lead to the disclosure of environment variables (`.env`), infrastructure configurations (`.htaccess`), installed packages versions, or even forgotten logs and database dumps, paving the way for further attacks.
## Suggested Mitigation
- **Input Validation & Whitelisting:** The `$classpath` must be strictly validated or whitelisted before being passed to `dol_include_once()`.
- **Execution Flow Correction:** The file inclusion logic must never be executed before the user's authorization has been fully verified.
- **Enforce Fail-Secure ACLs:** Modify `restrictedArea()` in `core/lib/security.lib.php` so that if the `$features` parameter is empty, access is explicitly denied (`$readok = 0`) instead of allowed by default.
## Disclosure Policy & Assistance
The reporter is committed to coordinated vulnerability disclosure. This vulnerability, along with the provided PoC, will be kept strictly confidential until a patch is released and explicit authorization for public disclosure is given.
Should any further technical details, logs, or testing of the remediation once a patch has been developed be needed, the reporter is available to assist.
Thank you for the time and commitment to securing Dolibarr.
Best Regards,
Vincent KHAYAT (cnf409)
## Video PoC
https://github.com/user-attachments/assets/4af80050-4329-4c88-8a54-e2b522deb844
## PoC Script
```python
#!/usr/bin/env python3
"""Dolibarr selectobject.php authenticated LFI PoC"""
import argparse
import html
import re
import urllib.error
import urllib.parse
import urllib.request
from http.cookiejar import CookieJar
LOGIN_MARKERS = ("Login @", "Identifiant @")
LOGOUT_MARKERS = ("/user/logout.php", "Logout", "Mon tableau de bord")
def request(
opener, base_url, method, path, params=None, data=None, timeout=15
):
url = f"{base_url.rstrip('/')}{path}"
if params:
url = f"{url}?{urllib.parse.urlencode(params)}"
payload = urllib.parse.urlencode(data).encode("utf-8") if data else None
req = urllib.request.Request(url, method=method.upper(), data=payload)
req.add_header("User-Agent", "dolibarr-lfi-poc/1.0-securitytest-for-dolibarr")
Red Hat OpenShift Container Platform is Red Hat's cloud computing
Kubernetes application platform solution designed for on-premise or private
cloud deployments.
This advisory contains the container images for Red Hat OpenShift Container
Platform 4.15.62. See the following advisory for the RPM packages for this
release:
https://access.redhat.com/errata/RHSA-2026:4418
Space precludes documenting all of the container images in this advisory.
See the following Release Notes documentation, which will be updated
shortly for this release, for details about these changes:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/release_notes/
Security Fix(es):
* Scrapy: python-scrapy: brotli: Python brotli decompression bomb DoS
(CVE-2025-6176)
* openssl: OpenSSL: Remote code execution or Denial of Service via
oversized Initialization Vector in CMS parsing (CVE-2025-15467)
* libpng: LIBPNG out-of-bounds read in png_image_read_composite
(CVE-2025-66293)
* expat: XML Entity Expansion (CVE-2024-28757)
* glib: Integer overflow in in g_escape_uri_string() (CVE-2025-13601)
For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.
All OpenShift Container Platform 4.15 users are advised to upgrade to these
updated packages and images when they are available in the appropriate
release channel. To check for available updates, use the OpenShift CLI (oc)
or web console. Instructions for upgrading a cluster are available at
https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html-single/updating_clusters/index#updating-cluster-cli.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing a content stream with a rather large `/Length` value, regardless of the actual data length inside the stream.
### Patches
This has been fixed in [pypdf==6.8.0](https://github.com/py-pdf/pypdf/releases/tag/6.8.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3675](https://github.com/py-pdf/pypdf/pull/3675).
As far as we are aware, this mostly affects reading from buffers of unknown size, as returned by `open("file.pdf", mode="rb")` for example. Passing a file path or a `BytesIO` buffer to *pypdf* instead does not seem to trigger the vulnerability.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the `/ASCIIHexDecode` filter.
### Patches
This has been fixed in [pypdf==6.7.5](https://github.com/py-pdf/pypdf/releases/tag/6.7.5).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3666](https://github.com/py-pdf/pypdf/pull/3666).
### Summary
The `<base>` tag passes through the default `Cleaner` configuration. While `page_structure=True` removes `html`, `head`, and `title` tags, there is no specific handling for `<base>`, allowing an attacker to inject it and hijack relative links on the page.
### Details
The `<base>` tag is not currently in the `page_structure` kill set. Even though the specification says `<base>` must be inside `<head>`, browsers accept `<base>` tags outside of the head.
If an attacker injects a `<base>` tag, it changes the base URL for all relative URLs on the page (links, images, scripts) to a domain controlled by the attacker.
### PoC
```python
from lxml_html_clean import clean_html
# The base tag is preserved in the output
result = clean_html('<base href="http://evil.com/"><a href="/account">Account</a>')
print(result)
# Output: <div><base href="http://evil.com/">...<a href="/account">Account</a></div>
```
### Impact
The injection of a `<base>` tag allows an attacker to hijack the resolution of **all** relative URLs on the page. This results in three critical attack vectors:
1. **Phishing & Redirection:** Attackers can redirect user navigation (e.g., `<a href="/login">`) and form submissions (e.g., `<form action="/auth">`) to an attacker-controlled domain, effectively stealing credentials or sensitive data without the user realizing they have left the legitimate site.
2. **Cross-Site Scripting (XSS):** If the victim application loads JavaScript files using relative paths (e.g., `<script src="assets/app.js">`), the browser will attempt to fetch the script from the attacker's domain. This upgrades the vulnerability from HTML injection to full Stored XSS.
3. **Defacement:** Relative references to images (`<img>`) and stylesheets (`<link>`) will be loaded from the attacker's server, allowing for UI redressing or defacement.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing the content stream using the RunLengthDecode filter.
### Patches
This has been fixed in [pypdf==6.7.4](https://github.com/py-pdf/pypdf/releases/tag/6.7.4).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3664](https://github.com/py-pdf/pypdf/pull/3664).
Unitree Go2 firmware versions 1.1.7 through 1.1.11, when used with the Unitree Go2 Android application (com.unitree.doggo2), are vulnerable to remote code execution due to missing integrity protection and validation of user-created programmes. The Android application stores programs in a local SQLite database (unitree_go2.db, table dog_programme) and transmits the programme_text content, including the pyCode field, to the robot. The robot's actuator_manager.py executes the supplied Python as root without integrity verification or content validation. An attacker with local access to the Android device can tamper with the stored programme record to inject arbitrary Python that executes when the user triggers the program via a controller keybinding, and the malicious binding persists across reboots. Additionally, a malicious program shared through the application's community marketplace can result in arbitrary code execution on any robot that imports and runs it.
Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.
This advisory contains the container images for Red Hat OpenShift Container Platform 4.14.62. See the following advisory for the RPM packages for this release:
https://access.redhat.com/errata/RHSA-2026:2973
Space precludes documenting all of the container images in this advisory.
See the following Release Notes documentation, which will be updated
shortly for this release, for details about these changes:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/release_notes/
Security Fix(es):
* Scrapy: python-scrapy: brotli: Python brotli decompression bomb DoS (CVE-2025-6176)
* openssl: OpenSSL: Remote code execution or Denial of Service via oversized Initialization Vector in CMS parsing (CVE-2025-15467)
* libpng: LIBPNG out-of-bounds read in png_image_read_composite (CVE-2025-66293)
* openssl: Out-of-bounds read & write in RFC 3211 KEK Unwrap (CVE-2025-9230)
* glib: Integer overflow in in g_escape_uri_string() (CVE-2025-13601)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
All OpenShift Container Platform 4.14 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html-single/updating_clusters/index#updating-cluster-cli.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing the `xfa` property of a reader or writer and the corresponding stream being compressed using `/FlateDecode`.
### Patches
This has been fixed in [pypdf==6.7.3](https://github.com/py-pdf/pypdf/releases/tag/6.7.3).
### Workarounds
If projects cannot upgrade yet, consider applying the changes from PR [#3658](https://github.com/py-pdf/pypdf/pull/3658).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires reading the file.
### Patches
This has been fixed in [pypdf==6.7.2](https://github.com/py-pdf/pypdf/releases/tag/6.7.2).
### Workarounds
If users cannot upgrade yet, consider applying the changes from PR [#3655](https://github.com/py-pdf/pypdf/pull/3655).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires a malformed `/FlateDecode` stream, where the byte-by-byte decompression is used.
### Patches
This has been fixed in [pypdf==6.7.1](https://github.com/py-pdf/pypdf/releases/tag/6.7.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3644](https://github.com/py-pdf/pypdf/pull/3644).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires parsing the `/ToUnicode` entry of a font with unusually large values, for example during text extraction.
### Patches
This has been fixed in [pypdf==6.7.1](https://github.com/py-pdf/pypdf/releases/tag/6.7.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3646](https://github.com/py-pdf/pypdf/pull/3646).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires accessing the children of a `TreeObject`, for example as part of outlines.
### Patches
This has been fixed in [pypdf==6.7.1](https://github.com/py-pdf/pypdf/releases/tag/6.7.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3645](https://github.com/py-pdf/pypdf/pull/3645).
The com.epson.InstallNavi.helper tool, deployed with the EPSON printer driver installer, contains a local privilege escalation vulnerability due to multiple flaws in its implementation. It fails to properly authenticate clients over the XPC protocol and does not correctly enforce macOS’s authorization model, exposing privileged functionality to untrusted users. Although it invokes the AuthorizationCopyRights API, it does so using overly permissive custom rights that it registers in the system’s authorization database (/var/db/auth.db).
These rights can be requested and granted by the authorization daemon to any local user, regardless of privilege level. As a result, an attacker can exploit the vulnerable service to perform privileged operations such as executing arbitrary commands or installing system components without requiring administrative credentials.
Red Hat OpenShift Container Platform 4.16.57 includes security updates addressing multiple vulnerabilities: a denial-of-service in github.com/sirupsen/logrus due to large single-line payloads (CVE-2025-65637), prototype pollution in lodash's _.unset and _.omit functions (CVE-2025-13465), and HTTP request smuggling in python-eventlet (CVE-2025-58068). These issues affect the container images and RPM packages of the platform. Users of OpenShift Container Platform 4.16 are advised to upgrade to the updated packages and images to mitigate these vulnerabilities.