SAP's October 10.0 is a library customers must upgrade, with a fixed build dated 53 days before the advisory

The 10.0 is a Python library, and its fixed build is dated 53 days before SAP's advisory

SAP's October patch day, Tuesday 13 October 2026, produced one flaw scored 10.0. It is CVE-2026-89111, an OAuth2 server-side request forgery (SSRF) in the SAP Cloud SDK for Python, published as a GitHub security advisory and not as a numbered SAP security note. The advisory gives the affected versions as below 0.45.2 and the patched version as 0.45.2. SAP's own release page for 0.45.2 is dated 21 August 2026, and PyPI's release history shows the same build uploaded that afternoon. From that release to the advisory is 53 days (derived: 10 days left in August, 30 in September, 13 in October).

What that does not establish. It does not say when SAP learned that the change fixed a security flaw. The release note files it under "Bug Fixes", with no security wording, and says that previously invalid values were "silently used to construct a malformed URL". The CVE record says the ID was reserved on 10 September, a date shared by the other October IDs read, so it does not date the discovery either. It does not say anyone has used the flaw: no SAP page read mentions exploitation, the CISA catalogue lists none of the month's 22 CVEs, and CISA's own entries dated 13 October on 19 of the 22 records say exploitation "none" (the 10.0 had no CISA entry when read). And it does not say the flaw is reachable in your deployment. SAP's text needs an attacker who "controls the tenant_subdomain parameter", and says nothing about where an application gets that value.

This briefing reads SAP's October overview page, the GitHub advisory and release notes, the CVE records, the CISA catalogue and PyPI's release history, all fetched between 19:54 and 20:16 BST on 13 October 2026. BleepingComputer's report of the same day, which calls the flaw maximum severity, was read in a browser tab as a pointer, not as evidence. SAP's notes themselves sit behind its login and were not read. Where a statement about a note comes from a security vendor's reading of it, the text says so.

The practical point is who acts. A library inside your own application is not patched by SAP on patch day, and it does not arrive through the support-package route SAP's administrators use. Someone has to find it, upgrade it and redeploy the application that contains it. The sections below count what SAP published, say what each Critical row reaches and who has to act, set out what is not established, and give the UK clocks and an ordered checklist.

Counting it SAP's way: 22 rows, 20 new flaws, 18 notes, and a label that is not on the page

SAP's overview says: "On 13th of October 2026, SAP security patch day saw the release of 16 new security notes and 4 GitHub security advisories. There are 2 updates to previously released security notes." The table of that page has 22 rows. The press figure of 20 flaws is the 16 plus the 4 (derived), and a security vendor's count of 18 notes is the numbered notes including the two updates (derived).

How the October numbers reconcile. Source: SAP's October 2026 overview page, read at 19:55 BST on 13 October 2026. Every count in the middle column is derived by this site from that table.

What is counted	Count	How it is made
Rows in SAP's table	22	16 new notes, 4 GitHub advisories, 2 updates to earlier notes.
New flaws	20	16 plus 4. BleepingComputer's "20 security flaws".
Numbered SAP notes	18	16 new plus 2 updates. RedRays, reading SAP for Me, also counts 18.
By SAP's priority, all rows	4 Critical, 3 High, 14 Medium, 1 Low	Counted from the Priority column.
By priority, numbered notes only	3 Critical, 3 High, 11 Medium, 1 Low	The same, with the 4 GitHub advisories taken out.
GitHub advisories	1 Critical (the 10.0), 3 Medium	The four rows whose first column is a GitHub advisory ID, not a note number.

The words "HotNews" and "Very High" do not appear on SAP's October overview, which uses Critical, High, Medium and Low (checked in the page source). RedRays, a vendor that sells SAP security tooling, says it reviewed SAP for Me, SAP's login-only notes portal, on 13 October and found 18 notes released that day: three HotNews, three High, eleven Medium and one Low. That matches the public table exactly once the four GitHub advisories are taken out (derived), and RedRays names the three HotNews as the 9.9, 9.9 and 9.1 notes. On that reading, the 10.0 is not one of SAP's HotNews: it is a GitHub advisory with no note number to appear in a note-driven worklist. That rests on a secondary reading of a page behind a login. SAP's public page does not say it.

What SAP says the 10.0 reaches, and why it scores 10.0

SAP's description, repeated in the advisory and the CVE record, is one sentence of mechanism. The Cloud SDK for Python "contains an OAuth2 SSRF vulnerability affecting multi-tenant BTP applications", and an attacker who controls the tenant value "can redirect OAuth2 token requests to an attacker-controlled server, causing client credentials to be exfiltrated." BTP is SAP's Business Technology Platform. So the request that is forged is the application's own request for a token, and what leaves is the application's client credentials. SAP's text does not say the forged request can reach internal systems or services behind the application, and it does not explain why integrity is scored High. A reading, labelled as inference: stolen client credentials can be used as the application against whatever they unlock, which would account for the integrity score, but SAP does not write that.

The fix, in SAP's words, is that 0.45.2 "validates the tenant_subdomain value against RFC 1123 DNS label rules before substituting it into a token URL". The release note names three code paths, the agent gateway client, the destination service token provider and the document management service authentication. The workaround is a single sentence: validate the tenant value "against a known allowlist of registered tenant subdomains before passing it to any SDK call". The package is on PyPI as sap-cloud-sdk, and its description lists features including the agent gateway, the destination service and the document management service, the same areas the release note names.

Who gave the 10.0? SAP did, as the CNA (the body that assigns the CVE ID and scores it). The NVD record read at 19:56 BST was in status "Received" with SAP's score as its only metric, so no second scorer had looked at it. The vector is network access, low complexity, no privileges, no user interaction, scope Changed, confidentiality High, integrity High, availability None. I recomputed the CVSS 3.1 base score from it and got 10.0 (derived). The score reaches 10.0 only because the scope is Changed: the same vector with scope Unchanged scores 9.1 (derived). Scope Changed means the impact lands on something outside the vulnerable component's own security scope, and it is a judgement by the scorer, here SAP.

The four Critical rows as SAP scored them, and the same vectors with scope left Unchanged. SAP's vectors from the CVE records; the last column is recomputed by this site (derived).

Row	Privileges SAP's vector needs	As published	Scope Unchanged (derived)
CVE-2026-89111, Cloud SDK for Python	None	10.0	9.1
CVE-2026-89110, Visual Composer	Low	9.9	8.8
CVE-2026-89107, S/4HANA rules	Low	9.9	8.8
CVE-2026-89108, Manufacturing Integration and Intelligence	High (administrator)	9.1	7.2

All four rows carry scope Changed, network access, low complexity and no user interaction (derived from the vectors). Take the scope change out and three of the four fall below the 9.0 line SAP's page calls Critical, to 8.8, 8.8 and 7.2 (derived). That is not an argument that the rows are over-scored. It shows that the headline number depends on one judgement about where impact lands, and that the other three rows depend on an authenticated user, in two cases a low-privileged one, and in one an administrator.

The four Critical rows: what each needs, what each reaches, and who has to act

The four Critical rows of SAP's October 2026 overview. Column two reads SAP's CVE records. Interim measures are as RedRays reports them from SAP notes this briefing could not read, except the 10.0, which is in the GitHub advisory.

Row, version field and note	Needs, and reaches (SAP's CVE text)	Who acts, and the interim measure
10.0, CVE-2026-89111. SAP Cloud SDK for Python, below 0.45.2. GitHub advisory, no note number.	No privileges, no interaction. Token requests redirected, client credentials leave.	The team that owns each Python application: upgrade, rebuild, redeploy. SAP's workaround: allowlist the tenant value.
9.9, CVE-2026-89110. SAP NetWeaver Visual Composer, VC70RUNTIME 7.50. Note 3797111.	Low privileges. Internal operations on a preconfigured remote system, up to full compromise of that system depending on the connection.	The SAP Basis team and the owners of the connected systems. RedRays reports an interim Secure Mode and a security default change in the note.
9.9, CVE-2026-89107. SAP S/4HANA (Manage Substitution/Validation Rules), S4CORE 105 to 109. Note 3805589.	Authenticated, specific business privileges. Input interpreted as ABAP code, full compromise of the system.	Basis and Finance. RedRays reports a temporary restriction on the rule-management service, which also blocks rule changes.
9.1, CVE-2026-89108. SAP Manufacturing Integration and Intelligence (Configuration Service), XMII 15.4 and 15.5. Note 3798788.	MII administrator privileges. An account with elevated privileges on the underlying Java application server.	The MII owner and Basis. RedRays reports branch-specific patches and no workaround in the note.

Cloud side and customer side. Counting only what the overview and the CVE records let me read, 0 of the 4 Critical rows say SAP has already fixed the flaw in a service SAP runs, and 4 of 4 name a version or package the customer holds (derived). The same count for the three numbered notes RedRays says SAP for Me labels HotNews is 0 of 3. In shares: 0 per cent cloud side, 100 per cent customer side (derived). The overview has no cloud-or-customer field, so this is a reading of the version column. It does not rule out that a note behind SAP's login says some SAP-run service was fixed centrally.

The first Critical row shows how little the word "cloud" settles. The library is for applications on SAP's cloud platform, yet SAP's advisory puts the fix in the customer's application. A High row shows it again: SAP Commerce Cloud's SQL injection (CVE-2026-89113, 8.8) lists COM_CLOUD 2211-JDK21, and RedRays reports that its note puts the correction in 2211-jdk21.18 or a later patch and that the deployment is not complete until the application is rebuilt and redeployed. Four of the 22 rows have the word Cloud in the product or library name, and all four list a version the customer holds (derived).

What the three numbered Critical notes have in common (derived from the vectors, since SAP does not say): each needs an authenticated user, in two cases low-privileged and in one an administrator; each has scope Changed; each is a component with a release number the customer installs. None has an exploitation statement from SAP in the pages read, and the CISA entries for all three say exploitation "none", automatable "no", technical impact "total" (13:02 to 13:07 UTC). Among the Critical and High rows, only two need no privileges at all (derived): the 10.0 library flaw and CVE-2026-58249 (7.5), a crash of the internet communication manager and Web Dispatcher by an unauthenticated request, which SAP rates for availability only. RedRays says it applies when HTTP/2 is supported and enabled. Of the 21 records with a CISA entry, that 7.5 is the only one marked automatable "yes". So the order of the scores and the order of reach differ: the highest-impact notes need a login, and the two rows that need none are a library and a crash.

Stated and not stated: the record on the 10.0, line by line

"Not stated" means not found in the sources listed, read in full. It does not mean the information does not exist.

What SAP's pages, the CVE record, CISA and PyPI state about CVE-2026-89111, and what they do not. Read between 19:54 and 20:16 BST on 13 October 2026.

The question	Stated	Not stated
Exploitation	No SAP page read mentions it. The [CISA catalogue](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) (version 2026.10.13, released 16:36 UTC) lists none of the 22 CVEs. CISA's entries dated 13 October on 19 of the 22 records say exploitation "none" (the two updated older records carry earlier entries). RedRays and SecurityOnline say none confirmed, and RedRays says it did no exploit validation.	Any SAP statement either way. Any CISA entry for the 10.0, which had none when read. Any threat-intelligence report. Nothing here says the flaw is not used.
Reachable without credentials, over the internet, in a default deployment	The vector says network, no privileges, no interaction. The text needs an attacker who controls the tenant value, in multi-tenant BTP applications.	Where an application gets that value. Whether any default configuration lets an outsider set it. Whether the affected code paths are on by default. Any exposure count.
Install base	BleepingComputer, a secondary source, says SAP serves 99 of the 100 largest companies. [pypistats](https://pypistats.org/packages/sap-cloud-sdk), third-party data, shows 117,870 downloads in the last month and 40,139 in the last week.	How many applications run a build below 0.45.2, or are multi-tenant. Downloads are not installs and include mirrors and build systems.
Affected builds	Below 0.45.2 per the advisory. PyPI lists 90 releases below it, from 0.1.0 of 16 March 2026, and 36 from 0.45.2 to 0.58.4 (derived).	When the flaw was introduced, and whether all 90 are affected. Whether 0.45.2 closes every code path, see below.
Workarounds	One, in the advisory: validate the tenant value against a known allowlist before any SDK call.	Whether the allowlist covers every code path. Workarounds for the other Critical rows from SAP's own pages: the notes were not read.
What the numbered Critical notes ("HotNews") share	Derived: authenticated access, scope Changed, customer-installed components with release numbers.	Any SAP statement on why they share a label, and whether they are internet-facing in default installs.
Public technical write-up	None found by 20:16 BST on 13 October beyond SAP's advisory and release notes. The two vendor blogs read restate SAP's text.	Any independent analysis or proof of concept. None is linked here.

One loose end matters to a defender. The 0.58.3 release note of 9 October 2026, four days before the advisory, describes a fix to how the per-tenant token address is derived in a different authentication provider, where a malformed or attacker-controlled address could result. SAP's advisory does not mention it. Whether that change is part of this CVE, a neighbour of it or unrelated is not stated. It is a reason to upgrade to the current release (0.58.4 on 13 October) and not to stop at 0.45.2 (inference).

Three 10.0 flaws in three months, a pattern in the libraries, and an empty 2026 column in CISA's list

SAP's ten 2026 patch days, from SAP's own overview pages, each read on 13 October 2026. Rows with a CVE ID, counted once per bulletin, updates included; rows without one are not counted (derived).

Patch day	CVE IDs listed	CVSS 9.0 or more	Highest score
13 January	18	4	9.9
10 February	28	2	9.9
10 March	15	2	9.8
14 April	20	1	9.9
12 May	16	2	9.6
9 June	16	4	9.9
14 July	21	4	9.9
11 August	31	4	10.0
8 September	22	4	10.0
13 October	22	4	10.0

Three of the ten 2026 patch days so far had a 10.0, the last three, one flaw each: CVE-2026-58231 in SAP Commerce Cloud's Data Hub Adapter on 11 August, CVE-2026-44756 in Extended Passport processing on 8 September, and this month's (derived from the ten bulletins). The seven before them topped out at 9.6 to 9.9. The count of patch days with a 10.0 is derived from SAP's pages. SAP does not state it.

The pattern in the libraries is easier to miss. SAP's overview began labelling some rows as "Library" in July. Three of its Critical rows are so labelled: the SAP Approuter node.js package (9.1, July), the multitenant credential disclosure in the CAP library @sap/cds-mtxs (9.4, September), and this SDK (10.0, October) (derived). In two consecutive months the Critical library flaw concerns credentials in multitenant applications. A library row is, in practice, fixed by whoever includes the library, with an upgrade and not a Support Package (inference). The October overview lists four library rows, all four of them GitHub advisories: the 10.0 and three scored Medium.

On exploitation history, the CISA catalogue file of version 2026.10.13, released at 17:36 BST on 13 October and read at 19:57, lists 14 SAP entries, 3 of them marked as used in ransomware campaigns, the latest added on 15 May 2025, 516 days before patch day, and none added in 2026 (derived). BleepingComputer says a threat-intelligence firm, Defused, flagged August's 10.0 as exploited days after its patch, and neither that flaw nor September's 10.0 is in the catalogue file read. The NCSC's guidance says catalogue entries "by their very nature" report only exploitation that has already occurred. Absence from the list is not evidence of safety, and it is not evidence of attack either. This site's earlier briefings on a 10.0 SSRF in SonicWall's SMA1000 gateways and on Cisco's October bundle read the same questions of score, reach and clock on other vendors.

Four friendly names: maximum severity, SSRF, cloud and HotNews

A label is not a control. Four appear in this story, and each hides a question about who patches.

Labels in the story, where each appears and what the record shows.

The label	Where it appears	What the record shows
"Maximum severity"	BleepingComputer's headline. The number is SAP's 10.0.	A score for the flaw as scored by SAP, not for your deployment. It reaches 10.0 because scope is Changed (9.1 otherwise, derived). It needs an attacker who controls a parameter whose source SAP does not state.
"SSRF"	The advisory title and the CVE weakness field (CWE-918).	Sounds like a request-forgery nuisance. SAP's text says the forged request is the token request and what leaves is client credentials. Whether it reaches anything further is not stated.
"Cloud" and "BTP"	The product names: Cloud SDK, Commerce Cloud, Cloud Connector, and the BTP platform.	"No action needed" is true only where SAP operates the service. Four rows have Cloud in the name, and all four list a version the customer holds. The 10.0 is a pip package the customer builds into its own application.
"HotNews"	SAP for Me, per RedRays. Not on SAP's public overview, which says Critical.	The three HotNews, on that reading, are numbered notes. The 10.0 is a GitHub advisory with no note number, so a HotNews-first policy would not list it.

Interests, stated plainly. SAP assigned the score and publishes the advisory about its own product. RedRays sells SAP security services, and SecurityOnline carries a subscription product for vulnerability alerts. Their coverage was read for counts and for what they say SAP's notes contain, and every such statement is marked as theirs. Method is separate from accusation: a patched build existed from 21 August, and the advisory arrived on patch day with a workaround. The gap is in what is stated, not in whether work was done.

The UK: 14 days to 27 October, the NCSC's shorter clocks, supplier risk and the ICO

Nothing read gives a count of UK SAP customers, so this section applies to any UK organisation that runs the components, large enterprise or public sector. The clocks below start on SAP's patch day, 13 October 2026. All dates are derived.

Clocks that start on SAP's 13 October 2026 patch day, with the arithmetic and the wording each rests on.

Clock	Date	Basis
SAP patch day	Tuesday 13 October 2026	SAP's overview page.
NCSC, internet-facing services and software	Sunday 18 October (5 days)	NCSC best-practice timescale, install on test or backup first, then roll out.
NCSC, operating system and applications	Tuesday 20 October (7 days)	The same table, phased rollout, pause or roll back on issues.
Cyber Essentials v3.3, and NCSC internal or air-gapped	Tuesday 27 October (14 days)	Updates fixing flaws the vendor calls critical or high risk, or CVSS v3 of 7.0 or above, within 14 days of release. 14 days remain from patch day. 7 of the 22 rows score 7.0 or above.
Fixed SDK build, if the clock ran from release	Friday 4 September (14 days after 21 August)	39 days before patch day. See the scope point below.
Next SAP patch day	Tuesday 10 November 2026	SAP's list of 2026 dates: 10 November and 8 December, 28 days after this one.

Cyber Essentials v3.3. The requirements document (April 2026) says software in scope must be updated, including vulnerability fixes, "within 14 days" of release where the vendor describes the flaws as "critical" or "high risk", the CVSS v3 base score is 7 or above, or the vendor gives no details of severity. It adds a caution that a vendor's single update covering several issues must be installed within 14 days if it covers any critical or high-risk one, which fits SAP's patch-day bundles. For the three numbered Critical notes, which name installable components, and the High rows on in-scope servers, the clock is 27 October as read. For cloud services the document says "the applicant organisation is always responsible for ensuring all controls are implemented, but some of the controls can be implemented by the cloud service provider". Its table lists security update management for platform-as-a-service as both the organisation and the cloud provider, and describes that model as the provider managing the infrastructure while "your organisation provides and manages the applications". A Python application on SAP's platform is the second case.

The scope point for libraries. The same document says, in its software development paragraph, that "Bespoke and custom components of web applications are out of scope", that publicly available commercial web applications are in scope by default, and that for the rest the best mitigation is "robust development and testing in line with commercial best practice", with a pointer to the Software Security Code of Practice. Read plainly, an in-house application built on the SDK may sit outside the 14-day rule altogether, which would make the question of whether a clock ran from 21 August or from 13 October moot for it. The document does not say whether a library pulled from PyPI into a bespoke application counts as bespoke. That is a question for the certification body, not a conclusion. It does not make the flaw less urgent. It means the control that applies to the library may be the organisation's own development process, not Cyber Essentials.

NCSC guidance. The NCSC's vulnerability management guidance (version 2.1, reviewed 1 May 2026) says to update by default and gives the 5, 7 and 14 day timescales above, which it says apply to all updates regardless of severity and can help organisations "develop contracts". It also warns that vendors "may publish advisories for some vulnerabilities" but "silently" update others, so missing an update could mean missing those. That is the shape of this story as the record stands: a build released as a bug fix on 21 August, a security advisory on 13 October. It is not a finding that SAP intended anything. On supplier risk, the NCSC's supply chain principles say that where suppliers use cloud services it is "not possible to transfer complete responsibility or accountability for protecting information to the provider of that service", "in every case", and to put minimum security requirements in contracts and require suppliers to pass them down. The active exploitation guidance adds that a rapid response process "will need to be reflected in supplier contracts".

Regulators. For operators of essential services, regulation 10 of the NIS Regulations 2018 requires "appropriate and proportionate" measures and regulation 11 notification of a NIS incident within 72 hours of awareness. The NCSC's Cyber Assessment Framework outcome B4.d, vulnerability management, says in its achieved column that announced vulnerabilities for software packages are "tracked, prioritised and mitigated (e.g. by patching) promptly", with no day count. If an affected system holds personal data, Article 32 of the UK GDPR requires the controller and the processor to implement appropriate measures, including "a process for regularly testing, assessing and evaluating" them. The ICO's breach guide says a reportable personal data breach must go to the ICO "within 72 hours of becoming aware of the breach, where feasible", and the ICO's security guide says that with a processor involved the written contract must stipulate the Article 32 measures and should require the processor to make available the information needed to demonstrate compliance. Article 28 requires a controller to use only processors providing sufficient guarantees. The ICO notes that the guide is under review because of the Data (Use and Access) Act. Whether stolen client credentials were used to read personal data, which would be the trigger, is a fact for your own logs, and the record read does not say.

The contractual question for managed landscapes. Where SAP, a hosting partner or an integrator runs the landscape, the contract decides who applies each note, who upgrades a library inside a managed application, and by when. Cyber Essentials expects that where a provider implements a control for you, the commitment is in "contractual clauses or documents referenced by contract", and that for externally managed services you can confirm the controls are met. Ask which of the 22 rows each party operates, which are closed, and on what date, and get it in writing.

What an assessor can ask. This is a reading, not a statement by the NCSC or a certification body. Expect questions on the scope boundary and whether the SAP application servers and any bespoke Python applications are inside it; the list of components and versions in scope; the release date of each fix and the date it was installed; evidence for the SAP notes by number and for the library by version; who signed off any interim measure and when it ends; for a managed service, the clause and the written confirmation; and for personal data, the log review and the breach decision. The government's Software Security Code of Practice, voluntary and aimed at vendors, adds that a vendor should have processes for managing vulnerabilities in components and should "provide timely security updates, patches and notifications to customers". It sets no day count, so whether 53 days between update and notification is timely is a judgement it leaves to the reader.

What to do, in the order worth doing

Every item is defender-level. The order follows the clocks above: know what applies, fix it, shut the exit, look back, get it in writing, plan the next cycle.

What could not be verified

• SAP's notes. The numbered notes sit behind SAP's login and were not read. Statements about interim measures, corrected releases and the HotNews label are RedRays's, and are marked as such.
• SAP Community. The Product Security Response Team's patch day post could not be fetched: the site answered with a bot check, which was not bypassed. SAP's own overview page was read instead.
• Exploitation. SAP says nothing either way in the pages read. The 10.0 had no CISA entry when read. Absence from these sources is not evidence.
• Introduction date and coverage. When the flaw entered the SDK, and whether 0.45.2 covers every code path, is not stated. The 9 October release note is a lead, not an answer.
• Where the tenant value comes from. SAP's text does not say, so reachability in any given application is unknown.
• Counts of downloads and installs. The pypistats figures are third-party and count downloads, not installs.
• Time-stamped. Sources were read between 19:54 and 20:16 BST on 13 October 2026. A CISA entry, an NVD score or a SAP note could change within hours.

The question that exposes the gap

When SAP's own overview calls something Critical and the fix is a library inside an application your organisation or a partner built, who sees it, who upgrades it, and by what date can you prove it was done?

Key facts