Check Point's LiteLLM flaws were fixed 179 days before its post; 1.83.9 is inside seven later advisories

Fixed on 17 April, published on 13 October: 179 days

LiteLLM 1.83.9, the release that closes both flaws named in Check Point Research's 13 October 2026 post, was uploaded to PyPI on 17 April 2026. That is 179 days before the post (derived). One of the two CVE records is older still: CVE-2026-35029 was published on 6 April, 190 days before the post (derived), and its fix, in version 1.83.0, had been on PyPI since 31 March. Check Point's technical post says the version it reviewed was 1.77.7, which was uploaded on 5 October 2025, 373 days before the post (derived). Its executive blog says coordinated disclosure to LiteLLM began in October 2025, and gives no day.

What the number does not establish is harm. Check Point reports no exploitation, and says it demonstrated its attacks "in a controlled test environment". Neither CVE is in CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.14, read at about 12:35 BST on 15 October), although three other LiteLLM flaws are. Zenity Labs, a security company, reports honeypot requests aimed at the first flaw from 7 April, one day after its CVE record, which shows scanning and not victims. No source gives a count of internet-reachable LiteLLM gateways running a version older than 1.83.9, or of gateways that hold production keys.

What the number does establish is narrower and more useful. The post reports findings whose fixes were already public, and the instruction that came with the coverage, update to 1.83.9, is not a safe place to stop: seven advisories published after that release list 1.83.9 inside their own affected range, one of them in the CISA catalogue (derived from LiteLLM's advisory list, set out below). Infosecurity Magazine, which reported the post on 15 October, also gives LiteLLM almost 100,000 downloads a month. Check Point's own blog says 97 million, roughly a thousand times more.

This briefing reads Check Point's technical post and executive blog in full, LiteLLM's GitHub advisories, the CVE.org and NVD records, the CISA catalogue, the PyPI release list, LiteLLM's documentation and blog, and independent write-ups by SEC Consult, Zenity Labs and Wiz. Infosecurity Magazine is read as a pointer only. Everything was read between about 12:30 and 14:00 BST on Thursday 15 October 2026, and any of it can change. The primaries print requests, paths, code and settings. This briefing reproduces none of them, and describes the weaknesses at the level a security lead needs.

Interests, in one sentence: Check Point, the author of the post, sells AI Agent Security and AI Red Teaming products and says it is the discoverer, while LiteLLM is made by a company that sells an enterprise edition of the same gateway and says it emails enterprise customers seven days before a major disclosure.

The record in date order, and what the post leaves out

The post prints no dates apart from its own, and the executive blog prints one month. The table puts the dates from the primaries in order. PyPI times are UTC dates.

Dates read from PyPI, the GitHub advisories and pull request, CVE.org, SEC Consult, Zenity Labs and Check Point (15 October 2026)

Date	What happened	Read from
5 Oct 2025	1.77.7 uploaded to PyPI: the one version Check Point says it reviewed	PyPI release list
Oct 2025, no day	Check Point says coordinated disclosure to LiteLLM began	Check Point executive blog
24 to 26 Feb 2026	SEC Consult finds the missing admin check (CVE-2026-35029) on 1.81.12 and reports it to the vendor	SEC Consult advisory
31 Mar	1.83.0 uploaded to PyPI: the fix for CVE-2026-35029	PyPI; LiteLLM advisory
3 Apr	LiteLLM publishes its advisory and a blog post that credits "Lakera" for CVE-2026-35029	GitHub; LiteLLM blog
6 Apr	CVE record published by GitHub as CNA: CVSS 4.0 8.7 High	CVE.org
7 Apr	First request to the affected route logged by Zenity's honeypots	Zenity Labs
16 Apr	The change that closes CVE-2026-59823 merged, titled "harden request parameter handling"	GitHub pull request
17 Apr	1.83.9 uploaded to PyPI: the fix for CVE-2026-59823	PyPI; LiteLLM advisory
21 Apr	SEC Consult publishes its own advisory for CVE-2026-35029	SEC Consult advisory
26 Aug	LiteLLM publishes its advisory for CVE-2026-59823: Moderate	GitHub repository list
16 Sep	CVE record for CVE-2026-59823 published: CVSS 4.0 5.3 Medium	CVE.org
13 Oct	Check Point publishes its technical post and its executive blog	Check Point
15 Oct	Infosecurity Magazine reports it	Infosecurity Magazine

Intervals, all derived. From the fix release to Check Point's post: 179 days for 1.83.9 and 196 for 1.83.0. From Check Point's report, which it dates only to October 2025, to the fix: 151 to 181 days to 1.83.0 and 168 to 198 days to 1.83.9. From the 1.83.9 release to LiteLLM's advisory for the second flaw: 131 days, and to its CVE record: 152 days. From the post to press coverage: 2 days. For the first flaw, SEC Consult's dates give a tighter series: reported on 26 February, fixed on PyPI 33 days later, CVE record 39 days after the report.

Who found CVE-2026-35029: three accounts, no overlap stated

LiteLLM's own post of 3 April lists CVE-2026-35029 under the words "Found by Lakera". SEC Consult's advisory presents the same CVE as its finding: found on 24 February on the then-latest version, reported on 26 February, and, in its words, assigned a CVE and disclosed "without further coordination" through LiteLLM's GitHub page on 3 April. Check Point's technical post lists the CVE among the issues it disclosed through a coordinated process, and gives no date. LiteLLM's GitHub advisory carries no credit at all.

One link is public. Check Point's press release of 16 September 2025 says it had agreed to acquire Lakera, with closing expected in the fourth quarter of 2025, and names Check Point AI Red Teaming and Check Point AI Agent Security as Lakera's flagship products. That makes it reasonable to read the "Lakera" that LiteLLM credits as the team now writing as Check Point Research. It is an inference. Neither LiteLLM nor Check Point says so. If it holds, the discoverer named in April and the author of the October post are one commercial group, with a product line in exactly this area.

None of this accuses anyone. Two researchers finding one missing check is ordinary, and the CVE could have been assigned against either report. What it shows is how little of the history a reader can reconstruct from the October coverage, and that the "disclosed" date in a headline is the date of a blog post, not of the first public record.

What each record states, and what it leaves out

The records are LiteLLM's two advisories (first, second), the CVE.org records (first, second) and the NVD pages (first, second). Both CVE records name GitHub as the CNA, the body that assigned the numbers, and carry its scores. The table sets them beside Check Point's account.

The two CVEs as recorded by LiteLLM, GitHub, CVE.org and NVD, set beside Check Point's posts and others (read 15 October 2026)

Question	Stated, and by whom	Not stated
Versions affected by the first flaw	Before 1.83.0 (CVE.org, NVD, LiteLLM). SEC Consult: up to and including 1.83.0. Check Point's blog: everything before 1.83.9	A lower bound. Check Point reviewed one version, 1.77.7. Zenity reports reproducing it on 1.74.0
Versions affected by the second flaw	Before 1.83.9 (CVE.org); up to 1.83.8 (LiteLLM's advisory)	A lower bound, or whether the stable and patch builds that carry other numbers are covered
Access needed	First: a user already authenticated (CVE record); a valid API key (LiteLLM's blog); any user, read only included (Check Point). Second: a valid virtual key (LiteLLM)	Whether the role matters. Wiz says a gateway with no master key grants every caller admin access, and one with the documentation's example key lets anyone forge sessions
What is exposed	First: settings, server files, admin accounts and code execution (CVE record). Second: requests to internal or external hosts the caller picks (CVE record). Provider keys (Check Point)	Provider keys in the second CVE's own text. A later record, CVE-2026-84377, states it
Score	First: CVSS 4.0 8.7 High from GitHub; 3.1 8.8 from NVD and Red Hat. Second: CVSS 4.0 5.3 Medium from GitHub. Check Point calls both high risk	Any CVSS 3.1 score for the second; NVD analysis is pending. Who set the numbers, the maintainers or GitHub
Weakness class	Incorrect authorization (CWE-863, GitHub; Red Hat adds CWE-425). Server-side request forgery (CWE-918)	Anything about how often either appears elsewhere in the code
Who assigned the CVEs	GitHub, as CNA, for both. The advisories are published on LiteLLM's repository	Which researcher's report each number was assigned against
What LiteLLM says to do	First: upgrade to 1.83.0, restrict API key distribution, no configuration-level workaround. Second: upgrade to 1.83.9 or later. Its pages add: stay on the latest stable release and upgrade if older than a month	A date to be done by, or a reason beyond the version number. Neither advisory says anything about rotating provider keys
Admin UI required	Check Point's account of 1.77.7 runs through sessions the admin UI creates. LiteLLM: no configuration-level workaround for the first flaw	Whether a gateway with the UI switched off is exposed

Two comparisons matter. The first is score against label. GitHub's CNA record scores the first flaw High and the second Medium (5.3), with low confidentiality impact. Check Point, and the coverage built on it, call both high risk. This briefing does not rescore either; it only notes that the two printed base scores are 3.4 points apart (derived), while Check Point's label does not separate them. The second is range against range. For 1.83.0 to 1.83.8, nine releases (derived from PyPI), the first flaw is fixed on the record, while Check Point's blog says every version before 1.83.9 is exposed to both.

The second CVE's text says a caller can send the gateway's own request to a host the caller chooses, and says nothing about provider keys. A separate record, CVE-2026-84377, published by LiteLLM on 26 August and by CVE.org on 2 September, describes a related weakness in plain terms: any authenticated user could cause the proxy to send its configured provider credentials to a destination the user controls. It is fixed in 1.88.6 and 1.96.2, not 1.83.9. Whether it is the same weakness Check Point's key theft describes is not stated by either side (inference: it is a neighbouring one).

A fix titled "harden request parameter handling"

The change that closes the second flaw was merged on 16 April under that title. Its description says it "addresses parameter handling inconsistencies in the proxy routing layer". The 1.83.9 release notes list it under the same title. Neither text names a vulnerability, a CVE or provider keys. The release is tagged as a nightly build on GitHub. The next plain stable tag after it is 1.83.10-stable on 27 April, and a patch build of 1.83.7-stable on 23 April sits between them; whether that patch build carries the fix is not stated. A team that follows only the stable tags would never have run 1.83.9.

The advisory followed 131 days later and the CVE record 152 days later (derived). LiteLLM explains the pattern in its September update: it says it is "minting more CVEs than before, mostly low and medium severity", and that the increase comes from a change in publishing policy. It also says that for anything an unauthenticated attacker can reach, it builds the fix privately and publishes the release, the backports and the disclosure together. Read together, that suggests the second flaw was fixed under the old practice and recorded under the new one (inference). It also means a fix can be public for months with nothing saying what it fixes.

The pull request adds one more detail a defender should know. It says the nested parameter is now gated by the same opt-in that governs other client-supplied connection settings, and that deployments which have switched that opt-in on are unaffected by the change. Read plainly, a gateway that allows callers to supply their own connection details still allows them to choose a destination, by design (inference). LiteLLM's later advisory for CVE-2026-84377 recommends turning that opt-in off.

The NCSC's update-by-default guidance names this case: vendors "'silently' update others, without public acknowledgement", and missing an update could mean missing those. Cyber Essentials v3.3 has a rule for it too, set out in the UK section.

1.83.9 is a floor, not a destination

LiteLLM's repository lists 17 published advisories on 15 October. Applying each advisory's own affected range to version 1.83.9, seven include it (derived). All seven were published after the 1.83.9 release, and between them they carry one critical, two high, three medium and one low rating as LiteLLM prints them.

Advisories whose stated affected range includes 1.83.9, from LiteLLM's repository advisory list (15 October 2026); severity as LiteLLM prints it

Advisory	What it is, as titled	Severity	Published (repository list); first fixed
GHSA-wxxx-gvqv-xp7p (CVE-2026-40217)	Sandbox escape in a custom-code guardrail	Medium	7 May; 1.83.10
GHSA-4xpc-pv4p-pm3w	Authentication bypass via Host header injection. LiteLLM says most deployments are not affected where an upstream layer checks the header	Critical	28 May; 1.84.0
GHSA-4g5m-c9r5-49xf (CVE-2026-59819)	Local file read via request-supplied OIDC file references	Low	30 Jun; 1.83.10-stable
GHSA-7488-6r32-c95q (CVE-2026-59822)	MCP authentication bypass via an OAuth2 passthrough fallback. In the CISA catalogue since 2 September	High	30 Jun; 1.84.0
GHSA-3cv6-jpf6-8222 (CVE-2026-84377)	Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters	Medium	26 Aug; 1.88.6 or 1.96.2
GHSA-hhww-mrg2-969h	Reflected cross-site scripting in an SSO debug callback	Medium	30 Sep; 1.85.0
GHSA-g5ff-637f-6q2m	Arbitrary local file read by a read-only internal user through a provider-credentials field	High	1 Oct; 1.95.0

A newer line has its own entry. GHSA-7hp6-4w63-5g45, published on 30 September with a critical rating, says an authenticated internal user could escalate to proxy admin and run commands on the host, in versions from 1.91.0 on. It starts after 1.83.9, so it is not one of the seven. It is a neighbour of the first Check Point flaw in class, and it was published 13 days before the post (derived). A team that moved to a newer release in August and then stopped has a different gap from one that stopped at 1.83.9, and LiteLLM's records show both.

LiteLLM's own advice is about cadence, not a version. Its August update says it backports security fixes across the last four minor release lines and that if you are on a version older than a month, upgrading is recommended. Its security best practices say to stay on the latest stable release, pin an exact version or image digest rather than the latest tag, and subscribe to its advisories. LiteLLM counts 24 security fixes in June, 38 in July, 79 in August and 52 in September, 193 in four months (derived from its own posts; the posts describe categories, not severities).

The arithmetic of a slow cycle is plain. PyPI shows 117 final releases across all maintained lines between 1.83.9 and 15 October, about 4.5 a week (derived). A team that updates once a quarter waits up to 91 days after any fix and 45.6 days on average (derived). In the 75 days from 17 April to 1 July, the first quarterly date after the fix, PyPI carried 53 final releases (derived). Against LiteLLM's one-month advice, a 91-day cycle is three times the age it recommends (derived).

One gateway, every provider key: what each flaw reaches

Check Point's blog describes the role plainly: the gateway is where applications' requests pass on the way to a provider, so it stores the API keys for every provider, manages access, routes prompts and responses and tracks cost. LiteLLM's documentation lists the roles that sit in front of that store: a platform admin, a read-only admin viewer, an internal user who can create keys, and a deprecated read-only internal viewer. The diagram shows where each flaw sits, as the records and Check Point describe them. It draws no technique.

The labels doing the work

Each phrase in the coverage is true as far as it goes. Each also hides something a defender needs. The table sets the label beside what the primaries say.

Phrases from Check Point, Infosecurity Magazine and LiteLLM's own pages, and what each hides (read 15 October 2026)

Label	What it hides	Where it is read
"Low-privileged", "read only"	A role is only as strong as the check behind it. Wiz found 294 of 3,074 internet-facing gateways (9.6 per cent) accepted the documentation's example key or had no key, and Zenity says its honeypot traffic overwhelmingly carried no key or a default one. For those, privilege is moot. LiteLLM says its new releases refuse to start with an unset or default master key	Check Point blog; Wiz (9 Sep); Zenity (1 Sep); LiteLLM September update
"Gateway"	It is a key store. The product's job is to hold the keys so applications do not. Wiz says LiteLLM is present in about a third of cloud environments it sees, which makes this a common single place for every provider credential	Check Point blog; Wiz
"Open source"	Visible code is not a patched estate. The fix here was visible from 16 April under a hardening title. LiteLLM's own March post says its PyPI releases 1.82.7 and 1.82.8 appear to have carried a credential stealer for about 40 minutes on 24 March, and that the official proxy Docker image was not affected	LiteLLM pull request; LiteLLM March post
"Coordinated disclosure"	A process, not a date. Check Point's starts in October 2025 and reaches public records on 3 April and 26 August 2026. SEC Consult says its own CVE was assigned and disclosed "without further coordination"	Check Point blog; SEC Consult; GitHub
"Familiar application security failures"	True, and still live. A missing check let a low-privilege account act as admin in the first flaw, and a critical advisory of 30 September describes an internal user reaching proxy admin on newer builds. Familiar is not finished	Infosecurity (a Black Duck manager); LiteLLM advisory list
"Full system takeover"	Check Point's phrase for what it showed in a test environment. It does not say what an attacker gets in a real deployment, which depends on the host's permissions, its network and its cloud role. Wiz describes paths from a gateway to cloud credentials, which depend on the same host permissions	Check Point; Wiz
"Almost 100,000 downloads a month"	Probably a slip of units (inference). Check Point's blog says 97 million, LiteLLM's home page says 92 million or more, and the third-party PyPI counter says 92.2 million for the 30 days to 14 October. Infosecurity's figure is 922 to 970 times smaller. LiteLLM adds that downloads count downloads, not installs or users	Infosecurity; Check Point blog; LiteLLM home page; pypistats

The downloads row deserves a line more. Nobody should read 92 million downloads as 92 million gateways: continuous-integration builds, mirrors and containers inflate the count, as LiteLLM's own footnote says. The only exposure count in a primary is Wiz's: 3,074 internet-facing gateways in February 2026, found through Shodan as Wiz describes it. Wiz adds that an August follow-up found more than 85,000, most of them honeypots or test systems, so the two cannot be compared. Dividing downloads by that count gives about 30,000 downloads for each gateway found (derived), a number that means nothing, which is the point.

Exploitation: what has been reported, and by whom

There are two honest answers, one per flaw. For the first, Zenity Labs' honeypot post of 1 September reports about 3,900 requests from 73 addresses against LiteLLM's admin interface between February and June 2026, about 1,000 of them to the configuration route, the first on 7 April and file-read attempts from 5 to 12 May. Zenity says in its June post that it builds detection rules for its platform from honeypot findings, so the post also serves its product; the data is a decoy's log, not a victim list. Zenity itself says the traffic overwhelmingly carried no key or a default master key and that it did not see low-privilege values in use; its post gives no count of compromised systems. For the second flaw, this briefing found no report of exploitation.

Exploitation of the two flaws, as stated by each source (read 15 October 2026)

Source	Stated	Not stated
Check Point's posts	Attacks demonstrated in a controlled test environment. No exploitation reported	Whether anyone has seen it in the wild
CISA catalogue, version 2026.10.14	Neither CVE is listed. Three other LiteLLM flaws are: CVE-2026-42208 (8 May), CVE-2026-42271 (8 June), CVE-2026-59822 (2 September)	Anything about exploitation not reported to CISA
CISA-ADP assessment inside the records	Exploitation none, as of 6 April for the first and 17 September for the second	A later view. It is a snapshot taken when each record was made
Zenity Labs, 1 September	About 3,900 requests, 73 addresses, February to June; first attempt on 7 April; file-read attempts 5 to 12 May; mostly no key or a default key	Any victim or any key stolen. Whether any request used a low-privilege key
Zenity Labs, 30 June	Almost 3,000 attempts from more than 20 addresses at a different SSRF, aimed at the master key and provider credentials	That it is the second flaw. Zenity names a connection-test route, not this CVE
Wiz, 9 September	Exploitation of CVE-2026-59822 seen on its honeypot from 7 July	Anything on either of the two flaws

An earlier briefing covered the botnet that hid its address in a poem; it used a LiteLLM flaw fixed 177 days before the report that named it, which is the same shape as this story. The lesson is not that these two CVEs are being used. It is that LiteLLM flaws that need a key have been listed by CISA as exploited (its note on CVE-2026-42271 says any authenticated user, including holders of low-privilege keys), and that Zenity logged the first attempt on the first flaw one day after its CVE appeared (derived).

What the record does not establish

Open questions that decide exposure, what the primaries give and what they do not (read 15 October 2026)

Question	What is established	Not established
How many gateways are reachable from the internet and unpatched	Wiz: 3,074 internet-facing in February 2026, 294 accepting a default key or none, found via Shodan as Wiz describes. Wiz: many more sit behind corporate networks and VPNs	A current count; the share on a version below 1.83.9; any UK figure
How many hold production keys	A gateway holds a key for each provider it is configured with (Check Point, LiteLLM)	Any count. A hobby or test gateway holds keys too
Whether the gateway's logs would show abuse	LiteLLM's [audit-log page](https://docs.litellm.ai/docs/proxy/multiple_admins) tracks keys, teams, users and models, and labels audit logs an Enterprise feature while also showing a switch for other plans. Its best-practice page says the shared environment login cannot be attributed to an individual	That a change to settings would appear (it is not among the listed entities: inference, not tested). Whether an outbound request carrying a key leaves any log
Whether forks and embedded copies differ	[Red Hat's record](https://access.redhat.com/security/cve/cve-2026-35029) rates the first flaw Important and lists fixed images for Ansible Automation Platform 2.6 and OpenShift AI 2.25 and 3.3, and one product with no fix listed. Check Point says LiteLLM often runs indirectly inside other tools	Which builds in which products carry which fix, or how many installations are embedded
What a stolen provider key allows	Check Point: direct, billable access with no further authentication, and unexpected costs	What any given key can do. Each provider sets key scope, spend limits and revocation, and neither post describes them
Whether the other bugs are fixed	LiteLLM fell twice at [Pwn2Own Ireland](https://www.pk-sharma.com/briefing/pwn2own-ireland-2026-ai-infrastructure-23-of-98-zero-days-15-percent-of-cash), and ZDI's standard disclosure clock is 120 days, so the bugs were not public as of 9 October	Their content or fix dates. Any fix will arrive as another advisory, which is a reason to watch the feed and not the version number

What this means for a UK estate, and where each rule stops

No source names a UK victim or gives a UK count, so what follows is about rules, not events. Each is read from the page named; none is legal advice.

NCSC update by default. The NCSC's guidance sets best-practice timescales: 5 days for internet-facing services and software, 7 for operating systems and applications, 14 for internal and air-gapped systems, applying to all updates whatever the severity. From the 1.83.9 release, 5 days ends on 22 April, 7 on 24 April and 14 on 1 May (derived). It stops at estate types: nothing in it says how to find a gateway a team stood up itself, or what to do about the keys it held while it was behind.

NCSC responding to active exploitation. The action table starts from whether a flaw is in the CISA catalogue, whether the product is internet-accessible, whether exploitation can be automated and whether an attacker can take total control, and sets times from under 24 hours to under 72 hours with an incident response provider. Neither of these two CVEs meets its first test on version 2026.10.14 of the catalogue, so the table does not yet apply to them. It does apply to the three LiteLLM flaws that are listed, if the gateway is internet-accessible. It stops at flaws that have been seen and listed; it says itself that a catalogue entry reports exploitation that has already happened.

Cyber Essentials v3.3. The scheme's requirements for IT infrastructure (April 2026) require in-scope software to be updated within 14 days of release where the update fixes vulnerabilities the vendor calls critical or high risk, scores 7 or above on CVSS v3, or comes with no details of the level of vulnerabilities fixed. A vendor that bundles several fixes in one update must be treated at its highest rating. For the first flaw, scored 8.8 on CVSS 3.1, 14 days from the 1.83.0 release ends on 14 April (derived). For 1.83.9, whose release notes gave no level, the third limb applies, and 14 days ends on 1 May (derived). Scope is the catch: the requirements cover in-scope software that can accept incoming connections from internet-connected devices or open outbound connections over the internet, and cloud services cannot be excluded. A gateway that calls providers does the second (inference), but whether it is in scope depends on how the organisation set its scope, which is for the assessor. The rule is a clock after release; it asks for no inventory of AI tools and no key rotation.

The AI Cyber Security Code of Practice. The government's voluntary code, published on 31 January 2025, asks operators to keep an inventory of assets and their interdependencies (provision 5.1), to evaluate access control frameworks for APIs (6.1), to follow secure software supply chain processes (7.1), to deliver security updates and patches (11.1) and to log system and user actions (12.1). It is principle-level: it sets no timescale, does not mention gateways or key custody, and being voluntary, binds nobody who has not adopted it.

The ICO and 72 hours. The ICO's guide says a report is due within 72 hours of becoming aware of a breach, where feasible, and that organisations must keep a record of every breach. A provider key is not personal data by itself (inference). The clock matters if the gateway keeps prompts, responses or logs that hold personal data and someone with admin reach could read them. Check Point lists routing prompts and responses among a gateway's jobs, so this is a question to answer, not to assume away. The guide stops at personal information. It does not mention keys, and awareness depends on records that show access, which, on the audit-log page, may not cover configuration changes.

What to do, in the order worth doing

The question that exposes the gap

If an ordinary account on your gateway had copied every provider key on 17 April, which record would show it, and who has read that record since?

Key facts