October 13, 2026 was a rough Monday for anyone running SAP S/4HANA or GitLab. Two separate disclosures hit the wire, both carrying severity ratings that make you stop scrolling. One is an authenticated code injection in SAP's ERP platform. The other is an unauthenticated remote code execution in GitLab's CI/CD pipeline. Different products, different attack vectors, same lesson: the bugs that matter most are rarely in the places you audited last quarter.
SAP S/4HANA: CVE-2026-89107 (CVSS 9.9)
The National Vulnerability Database assigned a 9.9 to CVE-2026-89107, a code injection flaw (CWE-94) in SAP's Manage Substitution/Validation Rules component. The vulnerability allows an authenticated attacker with specific business privileges to submit crafted input that the rule processing engine interprets as executable ABAP code.
The issue is insufficient input validation. SAP's substitution rules use a domain-specific scripting language to define business logic. When the system processes a rule definition, it fails to sanitize user-supplied data adequately. An attacker who can define or modify rules can slip ABAP statements through the parser. Those statements then execute as if they were legitimate application code.
This is not a buffer overflow or a memory corruption bug. It's a design problem: the system trusts rule input more than it should. The attacker needs valid credentials and the right business role. That sounds like a high bar, but in enterprise SAP deployments, rule management privileges are often handed out broadly because they're seen as configuration, not code execution.
S4CORE versions 105, 106, 107, and 108 are affected. The NVD record does not confirm a patch. Organizations running these versions should check SAP's official advisory channels. In the meantime, the practical mitigation is the boring one: review who has access to the Manage Substitution/Validation Rules feature and cut the list down to people who actually need it. If your organization treats rule authoring as a low-risk activity, this CVE is a good reason to revisit that assumption.
GitLab: CVE-2026-97229 (CVSS 10.0)
GitLab's vulnerability is worse in almost every way. CVE-2026-97229 carries a CVSS score of 10.0 with a vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That's network-reachable, no authentication required, full impact on confidentiality, integrity, and availability, with scope change. The vendor assigned the 10.0. vuln.today's analysis scored it 9.0, downgrading attack complexity from Low to High because the description says "under certain conditions." I'd lean toward treating it as a 10 until proven otherwise.
The flaw is an integer overflow (CWE-190) in how GitLab processes regular expressions in CI/CD configuration files. A specially crafted regex triggers insufficient validation, leading to memory corruption. An attacker who can supply that regex to a CI/CD pipeline can execute arbitrary code on the GitLab server.
The unauthenticated part is what keeps me up at night. GitLab says the issue affects all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. Public exploit code exists. The CVE record references two HackerOne reports (4055749 and 4058589). There's no CISA KEV entry yet, but that tends to lag behind reality.
GitLab is widely deployed as both a public-facing and internal service. CI/CD configuration files are often writable by a broad set of contributors. If an attacker can get a crafted regex into a pipeline, they own the server. From there, they can pivot to whatever the GitLab instance can reach. That includes source code, CI secrets, and anything on the internal network the host can access. The scope change metric in the CVSS vector (S:C) captures this lateral movement potential.
The pattern worth noticing
Both vulnerabilities share a root cause category: the system treats input as data when it should be treated as code. SAP's rule engine does this with substitution rules. GitLab's CI/CD parser does it with regular expressions. In both cases, the boundary between "configuration" and "executable logic" blurred to the point where an attacker could cross it.
I keep seeing this pattern. Domain-specific languages and templating systems are convenient, but they expand the attack surface in ways that traditional code review often misses. Security teams audit the application code. They don't always audit the DSL that the application interprets.
What to do now
For GitLab: check your version. If you're on anything below 19.2.8, 19.3.5, or 19.4.2, upgrade now. The patch is available. If you cannot upgrade immediately, restrict who can create or modify CI/CD configuration files, put the GitLab web interface behind a VPN or IP allowlist, and audit pipeline logs for unusual regex patterns. Given that public exploit code exists, I would treat this as an emergency change, not a routine patch cycle item.
For SAP S/4HANA: verify whether you're running S4CORE 105 through 108. If you are, review access controls for the Manage Substitution/Validation Rules feature today. Reduce the number of users with rule management privileges. Watch SAP's security notes for a fix. The lack of a confirmed patch is frustrating, but the authenticated requirement means this is less immediately dangerous than the GitLab flaw. It is still dangerous. An attacker with legitimate credentials and the right role can escalate to full ABAP code execution.
The uncomfortable takeaway
Enterprise software vendors have gotten very good at building extensibility features: rule engines, DSLs, template systems, pipeline configurations. These features make products flexible and customizable. They also create code execution paths that bypass the traditional vulnerability categories. The SAP and GitLab disclosures on October 13 are a reminder that "configuration" is often just code with a friendlier face. If your threat model treats configuration interfaces as low risk, these two CVEs should change that.