fix(deps): require pdfminer-six >=20251107 for VULN-92490

[shuningc]

Summary

Fixes VULN-92490 by upgrading pdfminer-six to >=20251107.

Prior to 20251107, CMapDB._load_data() in pdfminer.six uses pickle.loads() to deserialize CMap pickle files. A malicious PDF can specify an alternative directory and filename ending in .pickle.gz, causing arbitrary code execution when the PDF is processed.

Changes

• Add pdfminer-six = ">=20251107" direct dependency floor in pyproject.toml (matches idna/filelock/requests vuln-fix pattern)
• Regenerate poetry.lock (resolves 20260107, up from transitive 20250506)
• Transitive pdfplumber also bumps to 0.11.10 via lock resolution
• No example requirements.txt pins needed (pdfminer.six not pinned in examples)

Vulnerability

• Ticket: VULN-92490
• Package: pdfminer.six
• Fixed in: 20251107

Test plan

• poetry lock validates
• CI passes
• CrewAI optional extra still resolves correctly (pdfminer.six is a transitive dep via pdfplumber)

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: needs_discussion — The fix correctly raises pdfminer.six to a safe version, but converts it (and cryptography) from optional to mandatory for all installs, which needs a design decision.

[fercor-cisco]

this dependency should not be mandatory

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — Vuln is fixed in the lock, but the direct pdfminer-six floor is declared optional yet not in any extra, making it a dead declaration that doesn't enforce the intended floor.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• poetry.lock:4209-4243: The transitive bump also moves pypdfium2 4.30.0 -> 5.12.1 (a major version jump) and raises the Pillow floor to >=12.2.0, both via pdfplumber 0.11.10. These only apply under the crewai/all extras on python<=3.13 and src/ doesn't use them directly, so risk is low, but worth a smoke test of the CrewAI PDF path to confirm no regression from the pypdfium2 major bump.

[fercor-cisco]

🟠 major (design): pdfminer-six is declared optional = true here but is not referenced by any entry in [project.optional-dependencies] (the crewai/all lists). This makes it a dead/orphaned dependency:

• poetry install --all-extras (used by invoke install and CI) will NOT install it via this declaration — it's only pulled transitively through pdfplumber, so the direct floor never gates an install.
• poetry check (the poetry-check pre-commit hook) warns about an optional dependency that isn't part of any extra.
• Poetry omits unreferenced optional deps from the published package metadata, so a downstream pip install splunk-ao[crewai] would get no floor from this SDK. The vuln is currently avoided only because the regenerated lock happens to pin pdfplumber 0.11.10, which pins pdfminer to 20260107 transitively — not because of this line.

The stated goal ("guarantee a safe floor regardless of extras") isn't achieved by this declaration. Since the project uses PEP 621 [project.optional-dependencies], add the constraint to the crewai and all extras lists (e.g. "pdfminer.six>=20251107"), matching where the package actually ships. Alternatively, if you intend to rely purely on the transitive lock pin, remove this orphaned line to avoid the poetry check warning. Please confirm the intended approach.

🤖 Generated by the Astra agent

[shuningc]

updated

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-5). It may contain mistakes.

Verdict: approve — The dependency floor is now correctly wired into both the Poetry declaration and the PEP 621 extras, resolving the two prior major concerns; remaining items are minor design/metadata polish and a testing risk note.

General Comments

• 🟡 minor (security): Declared floor (>=20251107) is below the remediation version the ticket asks for (20251230).

VULN-92490 lists remediation: 20251230, while GHSA/CVE-2025-64512 lists 20251107 as the first fixed version. The lock resolves 20260107, so FOSSA (which scans poetry.lock, per the ticket's originPath) will see a satisfied version and the ticket should close.

The gap only matters for downstream consumers who install splunk-ao[crewai] from PyPI without this repo's lock: the published metadata permits 20251107–20251229, i.e. below what Splunk's own remediation guidance considers safe, and below any advisory fixed in that window. Since nothing in the resolution requires the lower bound, raising the floor to >=20251230 costs nothing and makes the published constraint match the ticket.

If 20251107 was chosen deliberately (e.g. to match the GHSA rather than FOSSA's recommendation), it'd be worth a one-line note in the PR body so the next person doesn't read it as an oversight.

• 🟡 minor (testing): Collateral transitive upgrades are unvalidated, and the test plan is entirely unchecked.

Bumping pdfminer.six is unavoidable-coupled to pdfplumber (0.11.7 pins pdfminer.six == 20250506 exactly), so pdfplumber must move to 0.11.10. But that drags in two more significant changes that aren't mentioned in the PR description:

• pypdfium2 4.30.0 → 5.12.1 — a major-version bump of a native PDFium binding, pulled in because pdfplumber 0.11.10 requires >=5.9.0.
• Pillow requirement >=9.1 → >=12.2.0.

Nothing in src/ imports pdfminer/pdfplumber/pypdfium2 directly and tests/test_crewai_handler.py doesn't exercise a PDF path, so CI passing gives no signal that crewai's PDF knowledge-source path still works after a major pypdfium2 bump. That's acceptable for a vuln fix, but the three test-plan boxes in the description are all unchecked — please confirm poetry lock --check / poetry check pass and that poetry install --all-extras resolves on the full 3.11–3.14 × 3-OS matrix (the new pypdfium2 5.x wheel set differs materially from 4.30.0's), and note the pypdfium2 major bump in the description so it isn't a surprise at release time.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• examples/agent/crewAI/research_crew/pyproject.toml:7-11: This example depends on crewai[tools]>=0.203.1 and plain splunk-ao (not splunk-ao[crewai]), so it inherits neither this PR's pdfminer floor nor the repo lock — it resolves pdfminer.six transitively via whatever pdfplumber crewai[tools] pulls. It's outside FOSSA's scan scope (the ticket's originPath is the root poetry.lock) and today's crewai releases pin a recent pdfplumber, so there's no live exposure. Still, consider either depending on splunk-ao[crewai] here or adding a lock/constraint so the example can't silently resolve to a vulnerable pdfminer for someone following the README.

[fercor-cisco]

🟡 minor (design): Missing the python = ">=3.11,<3.14" constraint that its siblings carry.

crewai (line 54) and litellm (line 49) are both gated to <3.14, and pdfplumber/pypdfium2/Pillow all retain python_version <= "3.13" markers in the regenerated lock. This declaration has no such gate, and the lock diff shows the effect: pdfminer-six's marker went from

python_version <= "3.13" and (extra == "crewai" or extra == "all")

to

extra == "crewai" or extra == "all"

and cryptography (pdfminer's native dep) likewise lost its python_version <= "3.13" guard for the crewai extra.

Concretely: on Python 3.14, poetry install --all-extras (CI, and invoke install) previously installed none of the PDF stack — crewai, pdfplumber, and pdfminer were all gated out. It now installs pdfminer.six plus cryptography on 3.14, where crewai and pdfplumber are still absent and nothing can use them. Not a break (pdfminer 20260107 needs >=3.10, and cryptography 49.0.0 ships cp314 wheels), just a compiled dependency added to a Python version that has no consumer for it.

Gating it matches the surrounding declarations and keeps the 3.14 install profile unchanged.

Suggested change

	pdfminer-six = { version = ">=20251107", optional = true }
	pdfminer-six = { version = ">=20251107", optional = true, python = ">=3.11,<3.14" }

🤖 Generated by the Astra agent

[fercor-cisco]

This is a minor edge case.

[fercor-cisco]

🟡 minor (design): Same gap as line 63, on the PEP 621 side: pdfminer-six (>=20251107) has no environment marker while crewai and litellm in the same list both carry ; python_version < '3.14'.

Since [project.optional-dependencies] is what ends up in the published wheel metadata, a downstream pip install splunk-ao[crewai] on Python 3.14 gets pdfminer.six + cryptography with no crewai and no pdfplumber to use them. Adding the marker here (in both crewai and all) keeps the extra internally consistent — pdfminer.six only ships where the thing that needs it ships.

Note both this and the line 63 change are needed; they feed different consumers (published metadata vs. Poetry's resolution/lock).

Suggested change

	crewai = ["crewai (>=0.152.0,<2.0.0); python_version < '3.14'", "litellm (>=1.83.14,<2.0.0); python_version < '3.14'", "pdfminer-six (>=20251107)"]
	middleware = ["starlette"]
	all = ["langchain-core", "langchain", "langsmith (>=0.8.0)", "openai (>=2.8.0,<3.0.0)", "packaging (>=24.2,<25.0)", "openai-agents (>=0.4.0,<1.0.0)", "crewai (>=0.152.0,<2.0.0); python_version < '3.14'", "starlette", "litellm (>=1.83.14,<2.0.0); python_version < '3.14'"]
	all = ["langchain-core", "langchain", "langsmith (>=0.8.0)", "openai (>=2.8.0,<3.0.0)", "packaging (>=24.2,<25.0)", "openai-agents (>=0.4.0,<1.0.0)", "crewai (>=0.152.0,<2.0.0); python_version < '3.14'", "starlette", "litellm (>=1.83.14,<2.0.0); python_version < '3.14'", "pdfminer-six (>=20251107)"]
	crewai = ["crewai (>=0.152.0,<2.0.0); python_version < '3.14'", "litellm (>=1.83.14,<2.0.0); python_version < '3.14'", "pdfminer-six (>=20251107); python_version < '3.14'"]
	middleware = ["starlette"]
	all = ["langchain-core", "langchain", "langsmith (>=0.8.0)", "openai (>=2.8.0,<3.0.0)", "packaging (>=24.2,<25.0)", "openai-agents (>=0.4.0,<1.0.0)", "crewai (>=0.152.0,<2.0.0); python_version < '3.14'", "starlette", "litellm (>=1.83.14,<2.0.0); python_version < '3.14'", "pdfminer-six (>=20251107); python_version < '3.14'"]

🤖 Generated by the Astra agent