Safeguard
Vulnerability Analysis•

CVE-2026-2654: SSRF in Hugging Face smolagents LocalPythonExecutor

CVE-2026-2654 is an SSRF in the smolagents LocalPythonExecutor when requests is authorized. No fix is listed; drop network modules and filter egress.

Safeguard Security Team
5 min read

CVE-2026-2654 is a medium severity (CVSS 6.3) server side request forgery in the LocalPythonExecutor of Hugging Face smolagents 1.24.0. If a developer authorizes the requests module for the agent, nothing limits where it can send requests. The vendor has not responded and no fix is listed. Limit network access instead.

What's affected

The NVD record names smolagents 1.24.0. The public report says the issue exists in the 1.x line, from 1.0 to the latest release as of February 2026, in src/smolagents/local_python_executor.py. The NVD record names the function calls requests.get and requests.post inside the LocalPythonExecutor component.

The record says the vendor was contacted early about the disclosure and did not respond. No patched version is named in any source we checked, so check the project's releases and security notices before you decide you are safe.

The report adds a condition that matters a great deal: the exposure arises when a developer allows the requests module through the additional_authorized_imports setting. If you never authorize it, the described path is closed.

How to check if you're exposed

First, find out whether you use smolagents and which version:

pip show smolagents
pip freeze | grep -i smolagents

Then search your code for the setting that opens the door:

grep -rn "additional_authorized_imports" .

If the list includes requests, httpx, urllib or any other module that can make network calls, the agent can reach whatever the host can reach. Note where the agent runs. An agent on a cloud instance can usually reach the cloud metadata service. An agent on a corporate network can reach internal services behind the firewall.

Finally, check who controls the agent's input. If users, web pages or documents can influence what code the agent writes, the risk is higher than for an agent that only runs your own scripts.

What to do now

  1. Remove network capable modules from additional_authorized_imports unless the agent needs them. If it needs web access, provide it through a narrow tool you wrote, which checks the destination, and not through a general purpose library.
  2. Add network level egress controls around the agent: allow only the hosts it needs and block internal address ranges and the cloud metadata address.
  3. On cloud hosts, require the metadata service version that needs a session token, and keep the hop limit low, so a request forwarded through an agent cannot pick up instance credentials. Check your cloud provider's documentation for the setting.
  4. Consider running agent generated code in an isolated executor instead of the local one. The smolagents project documents other executor options, so check its documentation for what fits your setup.
  5. Give the agent's host the least privilege you can: no instance role with broad rights, no secrets in environment variables, and no route to internal admin interfaces.
  6. Track the project for a fix, and upgrade as soon as the maintainers publish one.

Why it matters

The weakness is CWE-918, server side request forgery. The server makes a request on behalf of someone else, to a place that someone else chose. When the server sits inside a network, its requests carry the trust of that network. A request that an outsider could never send can come from the server instead.

The public report describes the root cause as an imbalance. The executor filters dangerous system calls by examining the code's syntax tree, which is meant to block code execution. It has no matching control for the destination of network calls made by modules the developer has authorized. The report lists consequences such as reaching cloud metadata services, probing internal services and sending data out of the network. Those are the report's claims; the CVSS vector in the NVD record, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, rates the impact as low on each axis, with low privileges required.

The NVD record says the exploit has been made public. It is not on the CISA Known Exploited Vulnerabilities list, and we found no statement that attacks are under way.

This is a good example of a pattern in agent frameworks. Teams add a library to an allow list for convenience, and the allow list becomes the security policy. An allow list of modules is not an allow list of behaviors. A module that can make any request can make a bad one.

The design lesson is to put controls where they cannot be talked out of. A prompt can be argued with. A firewall rule cannot.

If you review agent code regularly, add three questions to the checklist: what can this agent import, what can it reach on the network, and what credentials can it see?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Is there a fixed version of smolagents for CVE-2026-2654?

No fixed version is named in the record or the public report. The vendor did not respond. Check the project's releases.

Am I affected if I never authorize requests?

The report ties the issue to authorizing network capable modules. If you do not authorize them, the described path is closed, but you should still check what the executor can import.

Is it exploited in the wild?

The record says a public exploit exists. It is not marked as known exploited, and no source we checked reports attacks.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.