[sgrammargs]

Why

In October 2026 the private keys of eight eMudhra/emSign intermediate CA certificates leaked. certifi 2026.10.19 removes emSign ECC Root CA - G3, the root those TLS intermediates chain to. This PR moves poetry.lock from certifi 2026.7.22 to 2026.10.19 and raises the SDK's published minimum to certifi >= 2026.10.19, so SDK users get the fix too.

Fixed in	Socket Alert	CVE / Advisory	Summary
2026.10.19	none	none for certifi (related: CVE-2026-111943, Go's fix for the same incident)	Drops emSign ECC Root CA - G3 from the bundled CA store

No advisory ID covers certifi, so the branch is named after the target version. CVE-2026-111943 is Go's CVE for this incident, not a certifi advisory.

Exposure: certifi is a direct dependency (previously certifi >= 2024.2.2). ynab/configuration.py uses certifi.where() as the default ssl_ca_cert for every API call, so the SDK trusts exactly certifi's bundle.

Why 2026.10.19 is safe

certifi contains only the CA bundle plus where() / contents(). Between 2026.7.22 and 2026.10.19, core.py is unchanged; __init__.py changes only __version__. I parsed the bundles with openssl x509:

• Compared with 2026.7.22, the only change is that emSign ECC Root CA - G3 was removed (121 → 120 roots).
• AAA Certificate Services (Sectigo/Comodo) is not in 2026.10.19. The compromised intermediates also have copies cross-signed by that root, but with certifi alone those copies have no trusted root to chain to.
• emSign Root CA - G1, emSign Root CA - C1 and emSign ECC Root CA - C3 remain. The day before, 2026.10.18 had removed all four emSign roots. If any compromised intermediate chains to G1, this bump does not cover it.

Wheel sha256: 42d35340cc5b9ba78e818ddbff0c5b1c2b779de448a340fd1b989f5fa8670e1b (matches PyPI).

What changed

Two commits:

1. Lockfile: poetry update certifi --lock with Poetry 2.5.1, the version that generated the lockfile. A package-by-package diff of the lockfile shows only certifi changed.
2. Published minimum: certifi = ">= 2024.2.2" → ">= 2026.10.19" in pyproject.toml and templates/pyproject.mustache, so regenerating the SDK from the OpenAPI spec keeps the floor. Then poetry lock; Poetry 2.x keeps existing pins, so only content-hash changed.

Why raise the floor: the lockfile only affects this repo's dev/CI environment. This is a public SDK, and ynab/configuration.py defaults to certifi.where(), so users trust exactly the certifi they have installed. Raising the floor is the only way pip install -U ynab brings in the bundle without emSign ECC Root CA - G3.

Trade-offs for the release notes:

• An environment that caps certifi below 2026.10.19 can't install the new SDK version. dbt-snowflake is a known example: every release since 1.10.0 requires certifi<2025.4.26 (Why is dbt-snowflake still pinned to old version of certifi? dbt-labs/dbt-adapters#2230). Those users get a clear resolver error and can stay on the previous SDK version.
• Users who pass their own ssl_ca_cert, or get their packages from a distro, need to update their CA bundle themselves.
• The floor only reaches users once a new SDK version is published to PyPI.

requirements.txt (used by tox) doesn't list certifi; tox gets it by installing the package itself, which now enforces the floor. I left that file as is.

Verified

• poetry install then pytest: 162 passed (Python 3.10.20 from .tool-versions), after both commits.
• Confirmed the installed certifi reports 2026.10.19.
• poetry build → wheel METADATA contains Requires-Dist: certifi (>=2026.10.19).
• Installing that wheel with certifi==2026.7.22 is rejected by the resolver ("requirements are unsatisfiable"), so the floor is enforced.

🤖 Generated with Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​certifi@​2026.7.22 ⏵ 2026.10.19		+75

View full report

[bradymholt]

🤘

[github-actions]

The changes in this PR were just released in 4.4.1 🎉.