SSB-2026-003 - GhostLock Linux Kernel Privilege Escalation and Container Escape
| CVSS score v3.1 | |
|---|---|
| Base | 7.8 |
| Temporal | 7.4 |
| Environmental | 9.4 |
⚠️ Published: 2026-07-13. Last updated: 2026-07-13.
TLDR; A critical Linux kernel vulnerability known as GhostLock (CVE-2026-43499) was publicly disclosed on July 8, 2026, enabling local privilege escalation to root and container escape. We found no evidence that this vulnerability was exploited on Scalingo infrastructure or that any customer data was accessed. As an emergency response, we have upgraded all servers hosting our customers workloads to a Linux kernel version where the vulnerability is patched. The rollout was done between July 9 and July 10.
Introduction
On July 8, 2026, security researchers disclosed GhostLock, a 15-year-old use-after-free vulnerability in the Linux kernel’s mutex priority-inheritance subsystem. The NebuSec research paper describes an exploit chain achieving local privilege escalation to root in approximately 5 seconds with ~97% reliability, with a more advanced variant enabling container escape. The publicly released PoC demonstrates a kernel panic (denial of service) rather than the full escalation chain. On Scalingo’s PaaS platform, any deployed application constitutes a potential attack vector, as customers execute code inside containers on shared host nodes.
No patch was available for the current release of the Linux distribution version we were using. Only the last LTS release had a fix available. Scalingo had already planned the migration to this version and preliminary infrastructure work was underway. Given the severity of the vulnerability, we mounted an emergency response team and diverted resources to complete the remaining adaptation work, run QA, and execute the migration ahead of schedule.
Incident analysis
Disclosed publicly on July 8, 2026, CVE-2026-43499 (GhostLock) affects the Linux kernel’s rtmutex priority-inheritance code path (kernel/locking/rtmutex.c). A use-after-free condition in remove_waiter() allows an unprivileged local user to escalate to root. Exploitation requires only code execution inside a container, with no special capabilities, kernel modules, or sysctl configuration.
A public PoC (IonStack chain, NebuSec research) was released on the same day as disclosure. Scalingo confirmed exploitability internally on July 8 at 10:45: the PoC triggered a kernel panic on 2 out of 3 staging hosts, consistent with the DoS path demonstrated by the published code.
The NebuSec research paper describes a full local privilege escalation to root within the container, and a more advanced variant enabling container escape and cross-tenant host compromise. Scalingo did not independently reproduce the full LPE chain; however, given the root cause (use-after-free in a core locking primitive) and the credibility of the research, we assessed the LPE scenario as plausible and treated the vulnerability accordingly. Based on our monitoring, we found no evidence that any such attack occurred on Scalingo infrastructure.
Note: two regression vulnerabilities (CVE-2026-53166 and CVE-2026-53163) were introduced by the upstream fix. These cause kernel denial-of-service rather than privilege escalation, and no public exploit exists for them. We are actively monitoring for patches.
What we did
Scalingo took the following actions after the public disclosure:
- Assessed exposure across application nodes in
osc-fr1andosc-secnum-fr1, and verified that the affected kernel path was reachable from customer workloads running on the PaaS platform. - Reproduced the public proof of concept on staging hosts and confirmed the denial-of-service path. We did not independently reproduce the full local privilege escalation and container escape chain, but treated it as credible based on the upstream research and the kernel root cause.
- Determined that no reliable mitigation was available on the affected host OS release, and accelerated the already planned migration to the patched LTS release.
- Validated the patched kernel on the target release, completed QA for the emergency migration, and started the production rollout on application nodes.
- Added active monitoring during the rollout, temporarily suspended new account signups outside office hours as a precautionary measure, and tracked the two regression CVEs introduced by the upstream fix.
What you should do
No action is required for Scalingo PaaS customers.
This was a host OS migration only: your application stacks, runtimes, and dependencies were not changed. Applications were restarted during the migration. Thanks to Scalingo’s live migration technology, this was transparent: no requests were dropped and no data loss occurred.
If you observed unexpected behaviour in your application between July 9 and July 13 and suspect it may be related, please contact Scalingo support.
What we will do in the future
Two regression vulnerabilities in the Linux kernel fix (CVE-2026-53166, CVE-2026-53163) are being tracked as follow-up items. We are monitoring the distribution security tracker for patch availability and will apply fixes as soon as a patched version is published. We will update this bulletin when those patches are deployed.
Product Impacts
Scalingo PaaS
Application nodes in osc-fr1 and osc-secnum-fr1 were affected. All application nodes have been upgraded as of July 13th. This was a host OS migration only: application stacks, runtimes, and dependencies were not changed. Applications were restarted during the migration. Thanks to Scalingo’s live migration technology, this was transparent: no requests were dropped and no customer data loss occurred.
Scalingo DBaaS Add-ons
Database nodes are affected by CVE-2026-43499 at the kernel level. However, exploitation requires local code execution on the host, which is not directly accessible from customer database add-ons. Database nodes will be patched through Scalingo’s standard kernel update policy. Customers may review their configured maintenance windows to control the timing of this update.
Other Scalingo Add-ons and Services
Scalingo infrastructure handling application deployments was included in the OS migration. All these servers have been migrated as of July 13th. No customer-visible impact on build operations is expected.
Contact
If you have any questions or concerns regarding this bulletin, please contact Scalingo support at support@scalingo.com or through the in-dashboard chat.
Timeline
| Date and time | Milestone |
|---|---|
| 2026-07-08 09:25 | Vulnerability identified after public disclosure of CVE-2026-43499 (GhostLock). |
| 2026-07-08 10:15 | Exposure analysis started across application nodes in osc-fr1 and osc-secnum-fr1. |
| 2026-07-08 10:45 | Public proof of concept reproduced on staging; kernel panic confirmed on 2 out of 3 hosts. |
| 2026-07-08 11:05 | Determined that no reliable mitigation was available on the affected host OS release. Decision made to accelerate migration to the patched LTS release, which had already been planned. |
| 2026-07-08 15:00 | New account signups suspended outside office hours as a precautionary measure. Active monitoring started. |
| 2026-07-08 16:15 | Confirmed that the patched kernel version on the target release fixes CVE-2026-43499. |
| 2026-07-08 22:00 | Two regression CVEs identified: CVE-2026-53166 and CVE-2026-53163. No public exploit is known. |
| 2026-07-09 12:00 | QA testing for the emergency migration completed successfully. |
| 2026-07-09 18:55 | Production rollout of application nodes started. |
| 2026-07-09 22:15 | Rollout completed for region osc-secnum-fr1. |
| 2026-07-10 20:10 | No new application started on an impacted kernel version. |
| 2026-07-10 23:30 (CEST) | Rollout completed for region osc-fr1. |
| 2026-07-10 23:30 (CEST) | All application nodes in osc-fr1 and osc-secnum-fr1 are running the patched release. |
| 2026-07-13 18:00 (CEST) | All servers handling application deployment in osc-fr1 and osc-secnum-fr1 have been patched. |
Changelog
- 2026-07-13: Initial publication.