Two critical CVEs published this week on two unrelated open source projects: X-SpringBoot, a Spring Boot application scaffold, and Contrast, by Edgeless Systems, which runs confidential containers on Kubernetes.
The common thread: in both cases, the security mechanism exists and appears to work, but it doesn't check the thing that matters. A verification code that verifies nothing, an integrity policy that lets an unverified image through.
| X-SpringBoot | Contrast | |
|---|---|---|
| CVE | CVE-2026-97063 | CVE-2026-100833 |
| CVSS 3.1 | 9.1 CRITICAL | 9.6 CRITICAL |
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
| NVD published | 2026-09-25 | 2026-09-27 |
| Versions (NVD) | up to and including 6.0 | 1.14.0 to 1.23.0 |
| Fix | none mentioned | 1.23.1 |
| CISA KEV | no (as of writing) | no (as of writing) |
X-SpringBoot — CVE-2026-97063: the Login Code Handed to the Attacker
X-SpringBoot through 6.0 returns login verification codes in HTTP responses from unauthenticated endpoints [...] without sending them to account owners.
Login by SMS or email code rests on a single assumption: only the owner of the phone or mailbox receives the code. Here, the endpoints that generate these codes return them directly in the HTTP response, to anyone who calls them, without authentication.
The result: knowing a user's mobile number or email address is enough to log in as them. NVD explicitly calls it account hijacking. No victim interaction, no complexity — hence the 9.1.
NVD doesn't say how the flaw came about. It looks like a classic: a code echoed in the response to ease testing, never removed before production.
Versions and Fix
NVD says "through 6.0": every version up to and including 6.0 is affected, and no fixed version is mentioned at the time of writing. Check the project repository for a fix. Since X-SpringBoot is a scaffold you fork to build your own application, your derived code most likely inherits the flaw even if you no longer track upstream.
Detection
- In your code: do the SMS / email code controllers return the code in their response? A few minutes of review settles it
- In logs: an abnormal volume of code requests for different accounts from the same source
- Code-based logins with no matching SMS or email send on the provider side
Mitigation
- Remove the code from the HTTP response: it must only travel over SMS or email.
- Rate-limit code requests, per account and per IP address.
- Invalidate sessions opened by code since the flaw went to production, if logs can't rule out abuse.
Contrast — CVE-2026-100833: a Swappable Container Image
Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions.
Contrast runs containers in confidential execution environments (Kata Containers on memory-encrypting hardware). Its promise is strong: even the Kubernetes cluster administrator must not be able to tamper with the workload. What guarantees it is a runtime policy generated by Contrast, which pins the digests of allowed images.
According to NVD, a bad rebase during a Kata Containers update reintroduced a policy rule that accepts certain storage entries without verifying the image digest. An attacker with access to the Kata agent API — typically a cluster administrator, who is exactly inside Contrast's threat model — can then substitute a different image for the expected one, as long as it satisfies the remaining policy rules.
The PR:L might look reassuring. It isn't, here: the attacker Contrast defends against is someone with privileges on the infrastructure. The S:C reflects the break in the boundary the product promises.
Versions and Fix
NVD is explicit: versions 1.14.0 up to, not including, 1.23.1. Fixed in 1.23.1.
Detection
- Contrast version used to generate the policies for each deployment: any policy generated between 1.14.0 and 1.23.0 is affected
- Digests of images actually running in confidential pods, compared with the expected ones
- Kubernetes audit logs: changes to confidential pods or deployments by admin accounts
Mitigation
- Upgrade to Contrast 1.23.1.
- Regenerate runtime policies with that version and redeploy: updating the tool doesn't fix policies already generated.
- Review attestation: secrets released to workloads whose integrity wasn't guaranteed should be treated as exposed and rotated.
Why Continuous Monitoring of Open Source Dependencies Matters
Neither project shows up in a "traditional" software inventory: one is forked into in-house code, the other is an infrastructure tool. That's exactly where critical CVEs slip by unnoticed.
With cveo.tech, register your open source components and infrastructure tools too, and get alerted as soon as a critical CVE affects them.