GHSA-RPJ2-4HQ8-938G

GHSA-RPJ2-4HQ8-938G is a high-severity insecure deserialization vulnerability in vcrpy (pip), affecting versions < 8.2.1. It is fixed in 8.2.1.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

VCR.py: Arbitrary code execution via unsafe YAML deserialization of cassette files

vcrpy deserializes YAML cassette files with PyYAML's object-constructing loader (yaml.CLoader / yaml.Loader) instead of the safe loader (yaml.CSafeLoader / yaml.SafeLoader). A cassette containing a !!python/object/apply: (or similar) tag therefore executes arbitrary Python code the moment the cassette is loaded, including through the normal VCR().use_cassette() path, before any HTTP interaction is replayed.

This is not limited to environments lacking the libYAML C extension. CLoader uses the C parser but PyYAML's full Python constructor, so Python
object tags execute under CLoader exactly as under the pure-Python Loader. Confirmed against vcrpy 8.1.1 + PyYAML 6.0.3 with CLoader active.

Affected component

  • vcr/serializers/yamlserializer.py, deserialize()yaml.load(cassette_string, Loader=Loader) where Loader is CLoader/Loader. Reached on every cassette load.
  • vcr/migration.py (~line 107), yaml.load(preprocess_yaml(...), Loader=Loader). A second sink reached when the migration tool is run on a .yaml file. preprocess_yaml() only strips three known legacy tags, so other tags still execute.

Present in all releases inspected, 1.0.0 through 8.1.1.

Proof of concept

import vcr, requests

# Attacker-supplied cassette. The payload sits in an ignored top-level key
# so the rest of the cassette stays valid; it fires during load.
open("evil.yaml", "w").write("""interactions:
- request:
    body: null
    headers: {Accept: ['*/*']}
    method: GET
    uri: http://example.com/
  response:
    body: {string: ok}
    headers: {Content-Type: ['text/plain']}
    status: {code: 200, message: OK}
_x: !!python/object/apply:os.system ['touch /tmp/VCRPY_YAML_RCE']
version: 1
""")

with vcr.use_cassette("evil.yaml"):      # <-- /tmp/VCRPY_YAML_RCE created here
    requests.get("http://example.com/")

Loading the cassette creates /tmp/VCRPY_YAML_RCE, demonstrating arbitrary command execution. Any Python callable can be invoked this way.

Impact

Arbitrary code execution in the process that loads the cassette, with that process's full privileges. Realistic delivery paths:

  • A malicious cassette added in a pull request and loaded when CI runs the tests.
  • A poisoned shared test-fixture repository or cassette artifact store.
  • "Updated recorded HTTP fixtures" social-engineering.

Because cassettes are typically loaded by test suites in CI/CD and on developer machines, the exposed secrets are exactly the high-value ones in those environments: CI deployment credentials, cloud IAM roles, registry/publishing tokens, and source access.

Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect. Typical impact: arbitrary code execution or logic abuse.

GHSA-RPJ2-4HQ8-938G has a CVSS score of 7.8 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (8.2.1); upgrading removes the vulnerable code path.

Affected versions

vcrpy (< 8.2.1)

Security releases

vcrpy → 8.2.1 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Use the safe loader in vcr/serializers/yamlserializer.py:

try:
    from yaml import CDumper as Dumper
    from yaml import CSafeLoader as Loader
except ImportError:
    from yaml import Dumper
    from yaml import SafeLoader as Loader

def deserialize(cassette_string):
    return yaml.load(cassette_string, Loader=Loader)

Apply the same SafeLoader change in vcr/migration.py.

This is backwards compatible: vcrpy cassettes only contain standard YAML (scalars/lists/maps plus !!binary, all supported by SafeLoader/CSafeLoader), so existing cassettes load unchanged. vcrpy's serialize.deserialize() already catches yaml.constructor.ConstructorError, so a Python-tagged cassette now surfaces as the existing "old cassette format" ValueError instead of executing.

Recommended hardening: add a regression test that loads a cassette containing !!python/object/apply:os.system and asserts a ConstructorError/ValueError and that no side effect occurs.

Frequently Asked Questions

  1. What is GHSA-RPJ2-4HQ8-938G? GHSA-RPJ2-4HQ8-938G is a high-severity insecure deserialization vulnerability in vcrpy (pip), affecting versions < 8.2.1. It is fixed in 8.2.1. Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect.
  2. How severe is GHSA-RPJ2-4HQ8-938G? GHSA-RPJ2-4HQ8-938G has a CVSS score of 7.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of vcrpy are affected by GHSA-RPJ2-4HQ8-938G? vcrpy (pip) versions < 8.2.1 is affected.
  4. Is there a fix for GHSA-RPJ2-4HQ8-938G? Yes. GHSA-RPJ2-4HQ8-938G is fixed in 8.2.1. Upgrade to this version or later.
  5. Is GHSA-RPJ2-4HQ8-938G exploitable, and should I be worried? Whether GHSA-RPJ2-4HQ8-938G is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-RPJ2-4HQ8-938G is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-RPJ2-4HQ8-938G? Upgrade vcrpy to 8.2.1 or later.

Stop the waste.
Protect your environment with Kodem.