Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
aiograpi versions before 0.9.10 accepted server-supplied signup challenge paths and used them to build request URLs before validating that the paths were relative Instagram API paths. A malicious or tampered challenge payload could cause challenge handling requests to be sent outside the intended Instagram host with the client\'s existing session headers. Version 0.9.10 validates challenge paths before building URLs, solving captcha challenges, or submitting phone/SMS challenge forms.
Recommended action: Upgrade to 0.9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact aiograpi 0.6.6 / 0.7.0 / 0.7.1 declared orjson==3.11.6 (and later ==3.11.8) in requirements.txt but setup.py carried a hard-coded duplicate requirements = [...] list that was never updated and still pinned orjson==3.11.4. When setuptools builds the source distribution it reads the metadata from setup.py, not from requirements.txt. So pip install aiograpi==0.6.6 (or 0.7.0 / 0.7.1) actually pulls orjson==3.11.4 — a version vulnerable to CVE-2025-67221 (stack overflow in orjson.dumps on deeply nested JSON inputs). Practical exploitability Low in the typical aiograpi flow: orjson is used to encode request bodies aiograpi itself constructs and to decode responses returned by Instagram. An attacker would need to coerce aiograpi to encode an attacker-controlled deeply-nested Python structure or to decode an attacker-supplied stream — not the normal call shape. However any caller doing client.publicrequest(...) or similar with caller-controlled payloads, or any caller passing…
Recommended action: Upgrade to 0.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.