Patch Pydantic AI stalls and check traces for exposed credentials

Pydantic announced security updates on November 4, 2026, for teams running AI assistants that fetch untrusted web content, scan text for secrets or record embedding requests for diagnostics. Maintainers describe inputs that can disrupt other requests in the same process, plus a separate flaw that can put credentials into diagnostic records.

The practical task is to identify affected configurations, install compatible patches and review any credentials captured before the update. These advisories describe possible effects; they do not establish exploitation in the wild.

Check which paths your application uses

Start with the package versions installed in the running service, then check its configuration. Using an AI chatbot, Python or the separate Pydantic validation library does not by itself establish exposure to these flaws.

Fetching pages locally

The local-fetch advisory is rated High, with a severity score of 7.5 out of 10. It affects applications using web_fetch_tool or the local fallback of WebFetch on URLs an attacker can influence. Formatting a nested JSON response can consume excessive memory and stall other requests, even when download and returned-content limits are set. Provider-native fetching is outside this particular flaw.

Affected versions of pydantic-ai and pydantic-ai-slim are 1.77.0–1.107.9 and 2.0.0b1–2.65.0, inclusive. The current WebFetch documentation describes native-only behavior by default, with local=True enabling a bundled fallback. Check the actual deployed route; do not assume today’s default describes an older installation.

Scanning text for secrets

The Harness redaction advisory is also rated High, at 7.5. It covers pydantic-ai-harness 0.16.0–0.65.0 when redact_secrets or secret_data() uses the private_key pattern on attacker-influenced text. That pattern is included by default. Input, tool-result and output guards can all provide an affected path.

Maintainers say a short crafted input can occupy the event loop—the mechanism coordinating concurrent work—for minutes or longer. The consequence can extend beyond the offending request to other work in the same process.

Recording embedding diagnostics

Embeddings represent text numerically for tasks such as search. Traces are diagnostic records of requests. The embedding-trace advisory is rated Moderate, at 6.5, and affects core/slim versions 1.39.0–1.107.9 and 2.0.0b1–2.65.0.

The exposure requires embedding instrumentation and credentials supplied through extra_headers or extra_body. People able to read exported traces could then see those credentials. Neither include_content=False nor include_model_request_parameters=False prevents this recording. The advisory excludes chat-request and image-generation spans from this particular issue.

Check global setup as well as individual embedding objects: Embedder’s instrumentation settings can inherit the value set through Embedder.instrument_all().

Choose a compatible patch

These patch releases are available on PyPI. Keep the distribution and optional provider dependencies your application already uses; a slim installation does not need to become a full installation.

The dependency distinction matters: an affected v1 core application has a same-major-version fix. But Harness 0.66.0 pins slim to 2.66.0, so combining that Harness patch with a slim 1.107.10 pin is not a compatible option. Updating core alone also does not establish that Harness has been patched.

Update through the project’s dependency and lockfile workflow, rebuild and redeploy, then verify resolved versions in every serving environment. Review the release compatibility notes for features you use. If the upgrade also crosses 2.65.0, check the separate change to refusal and fallback routing.

The earlier streaming concurrency-limiter issue has a different cause. Its historical version recommendations are not the patch targets for these November advisories.

If patching must wait

• Local fetching: the maintainer workaround is to restrict fetching to trusted hosts with allowed_domains or use provider-native fetching.

• Harness: the temporary workaround is to select needed detector patterns with secret_data(only=[...]) while excluding private_key. The ellipsis is a placeholder, not usable configuration. This removes private-key detection, so plan to restore that coverage after patching.

• Embedding traces: the advisory recommends keeping credentials out of those settings, for example through provider-client configuration, or temporarily setting instrument=False on Embedder.

These are targeted workarounds, not complete protection for the broader security release. Disabling embedding instrumentation also removes those diagnostics; account for that loss while the workaround is in place.

Review historical traces separately

The patched embedding implementation omits the two request-override fields from newly recorded settings. Upgrading changes what future traces record; it does not remove credentials from historical traces.

For affected embedding configurations, follow the advisory’s cleanup guidance: restrict access to historical traces and rotate credentials they exposed. Have the application owner and telemetry owner review retained records together, inside the controlled telemetry environment. Do not copy secret values into tickets or chat.

A suggested acceptance check is to send a controlled embedding request using synthetic, non-secret marker values, then inspect exported attributes. Based on the released filtering code, neither override field should be recorded in embedding settings. Check that the diagnostics you intend to retain still work. This verifies the application’s recording path, not the removal of earlier exports.

Treat the work as two separate completion checks: patched code is running in the affected services, and any historical credential exposure has been handled. A successful version check does not settle the second.