GHSA-rpj2-4hq8-938g
HIGHGHSA-rpj2-4hq8-938g is a high-severity (CVSS 7.8) remote code execution vulnerability in vcrpy. O3 Security confirms whether GHSA-rpj2-4hq8-938g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
VCR.py: Arbitrary code execution via unsafe YAML deserialization of cassette files
Blast Radius
vcrpyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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)whereLoaderisCLoader/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.yamlfile.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.
Patch
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | vcrpy | all versions | 8.2.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vcrpy. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update vcrpy to 8.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rpj2-4hq8-938g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rpj2-4hq8-938g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rpj2-4hq8-938g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rpj2-4hq8-938g in your dependencies?
O3 detects GHSA-rpj2-4hq8-938g across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.