Skip to content
folhas.io
secure by design for connected products· Articles

Articles

The rest of the stack: Linux kernel, Python, certificates

The PHP2Shell week also brought fixes for the Linux kernel, for Python and for the certificate store. For manufacturers, the question is the same at all three layers: by what route, and with what delay, the fix reaches the devices already sold.

Published

Article 09 followed the PHP and Node.js fixes of 21 Oct 2026. The same week brought work for the rest of a connected device’s stack: two rounds of Linux kernel flaws, new Python security releases, with a tarfile fix still to be released, and the compromise of eight eMudhra intermediate certificate authorities, which forced changes to the certificate stores of browsers, operating systems and programming languages.

This article is a defensive record, written from the manufacturer’s side: what each case is, who is affected, which versions fix it and what to check in the product. Exploitation details are left out. The statuses cited are those of 23 Oct 2026, and some will change in the coming days.

The stack of a connected device in four layers, with what came out in October 2026 and who delivers the fix. Application and update agent: Python's tarfile and ssl, with fixes released between 30 September and 21 October and CVE-2026-114583 still without a fixed release on 23 October; the fixed release comes from CPython, and the application's share belongs to the manufacturer itself: server_hostname, filter='data' and a signature verified before extracting. Python, Node.js and PHP runtimes: Python 3.10 at end of life since 1 October, 3.11 and 3.12 without the new pip; the fix comes from the upstream project, through a distribution or the build system. Certificate store built into the firmware: emSign ECC G3 root removed in NSS 3.131.1 and in certifi 2026.10.19, eMudhra intermediates revoked; the fix comes from Mozilla, certifi and the distributions, and only reaches the device with an update. Linux kernel from the SoC vendor's BSP: PwnEscape fixed on 15 October, Infinity Core with public exploits on 16 October and fixes in the stable kernel since 27 August; the fix comes from the SoC vendor, based on kernel.org, with the question of which branch and with what delay. Underneath, the manufacturer's update is the only route to the devices already sold, at any layer.
Each layer has its own fix path, and the kernel's usually goes through the SoC vendor's BSP.

PwnEscape: the host kernel

CVE-2026-99999, known as PwnEscape, was published on 15 Oct 2026 by the Linux kernel CNA with the title “ipv4: validate checksum_start before completing checksum”. It is a flaw in the IPv4 stack: a packet with invalid checksum metadata can lead the kernel to corrupt the network header. The commit message describes the fix as defence in depth and says that more complete validation on input still needs work. According to the CNA, the flaw has existed since Linux 2.6.27, from 2008.

Paulos Yibelo (PWNAI Research) found it, in the challenge Vercel launched on 18 Aug 2026 against its sandbox service. Vercel says it was the most serious finding of the programme and separates what was seen where: the continuous leak of host memory was demonstrated against production sandboxes, while crashing the host and running commands with administrator privileges were only demonstrated on the researcher’s own machines, configured like the service. No report showed access to customer data.

The kernel that has to be updated is the host’s. AWS tells customers who manage their own virtual machines with virtio-net, including Firecracker, to update and reboot their KVM hosts, says that EC2, Lambda and Fargate are not affected and that there is no workaround. Red Hat allows for two kinds of attacker, an untrusted guest virtual machine or a local attacker, and it too knows of no mitigation that meets its criteria. The CNA stresses that this is not an Internet receive path.

The ratings differ. The kernel CNA scores it 9.3 in CVSS 3.1 (critical) and Red Hat 8.8 on the same scale (important), a difference that, according to Red Hat, lies only in the privileges required. Ubuntu gives it medium priority.

The fixed stable releases all came out on 15 Oct 2026: 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 and 5.10.272. In mainline, the fix is in 7.3, released on 18 Oct. Among the distributions, as of 23 Oct, Debian had already fixed it in trixie (16 Oct) and bookworm (17 Oct), and Red Hat in RHEL 10 (19 Oct) and RHEL 9 (20 Oct). The main RHEL 8 kernel was still unfixed, and Ubuntu had not yet published a fixed package.

For a manufacturer, the question is whether the product runs third-party code in virtual machines on Linux, such as a gateway that hosts customer workloads. A single-purpose device, with no virtual machines, falls outside the scenario the CNA describes. Red Hat also mentions a local attacker and scores it with low privileges (PR:L), without describing what concrete access is needed. For a product that lets users install third-party applications, that is a question to put to the kernel supplier. The manufacturer’s own infrastructure may fall within the scenario: the cloud the devices connect to and the build servers, if they run self-managed virtual machines or microVMs.

Infinity Core: exploits for weeks-old fixes

On 16 Oct 2026, once the embargo agreed with the linux-distros list had ended, Hyunwoo Kim published on oss-security the set he called Infinity Core: six flaws in the kernel’s Timer, Signal, MM, Futex, Scheduler and SLAB subsystems, which according to the author can be used to escalate privileges on Linux servers and on Android and to escape containers. In the researcher’s public repository, five of the six have a proof of concept that takes an unprivileged account to root; the sixth (SLAB) only has a trigger that makes the kernel halt. The Timer flaw was also used to gain root on a Samsung Galaxy S26 Ultra from an app with no additional permissions. That exploit has not been published, but the researcher says he will publish it once the Galaxy devices are fixed, or earlier if a third party publishes one. The October Android security bulletin, of 5 Oct, includes none of the six.

What makes the case relevant to manufacturers is the timeline. The fixes were in some of the kernel.org stable branches well before disclosure:

FlawCVEAffected sinceFirst fixed stable releasesDays before 16 Oct
FutexCVE-2026-807756.176.18.47, 7.1.11, 7.2.1 (27 Aug)50
MMCVE-2026-897547.0 (and 6.18.21 to 6.18.49; 6.19.11 onwards, unmaintained branch with no fix)6.18.50, 7.2.4 (7 Sep)39
SLABCVE-2026-979417.27.2.7 (21 Sep)25
TimerCVE-2026-982605.76.18.54, 7.2.8 (25 Sep); 6.6.158, 6.12.112 (3 Oct)21
SignalCVE-2026-982566.156.18.54, 7.2.8 (25 Sep)21
SchedulerCVE-2026-983857.27.2.9 (3 Oct)13

All six CVE records were already public before 16 Oct (the last, the Scheduler one, on 12 Oct), with commit titles that make no mention of privilege escalation. Anyone applying the full stable releases of the 6.6, 6.12, 6.18 and 7.2 branches already had the fixes before the exploits were public. In the 6.1, 5.15 and 5.10 branches, which the Timer flaw also affects, the fix had still not come out on 23 Oct.

The distributions were not all at the same point. Debian fixed the Timer flaw in trixie on 16 Oct and in bookworm on 17 Oct, and the other five do not exist in the code of its stable releases. Red Hat fixed Timer and Signal in RHEL 10 on 19 Oct and Timer in RHEL 9 on 20 Oct; the Futex flaw remained unfixed in the RHEL 10 kernel. Ubuntu 26.04, on whose kernel the researcher tested four of the proofs of concept, had on 23 Oct no published security notice for any of the four that affect it, only the status “work in progress”. The 7.0 branch that kernel is based on is no longer maintained on kernel.org (the last release, 7.0.14, came out on 27 Jun 2026), so each fix depends on Canonical backporting it. None of the six is in CISA’s KEV catalogue (version of 21 Oct).

And the device’s kernel?

In an embedded device, the kernel often comes from the SoC vendor’s BSP, derived from a kernel.org branch and with changes of its own. A study presented at USENIX Security 2026 (Badola et al.), covering 900 firmware images from 306 small office and home devices, found 11 of 40 SoC SDK kernels on Linux branches already at end of life when they were used, and only in 12 of 174 cases did the final firmware have a newer kernel than the SDK’s. The five SoC vendors in the study all used SDKs with kernels that had been at end of life for more than a year. Older data on Android (USENIX Security 2021) points the same way: for about half of the CVEs, the fix only reached the manufacturers’ devices 200 days or more after the upstream fix.

We found no public advisories from SoC vendors on the CVEs in this article. The questions fall to the manufacturer, and it is best to ask them in writing:

  1. Which kernel.org branch is the BSP kernel derived from, and up to which stable release is it synchronised?
  2. With what delay does the vendor integrate stable releases, and through which channel does it notify customers?
  3. Are the fixes for CVE-2026-99999 and CVE-2026-98260 already in the BSP? In the 6.1, 5.15 and 5.10 branches, the second had not yet come out on kernel.org on 23 Oct: for 6.1 it had been in the stable review queue since 3 Oct, for 5.15 and 5.10 not even that.
  4. What happens to the BSP when the branch reaches end of life? On kernel.org, 5.10 and 5.15 end in December 2026, 6.1 and 6.6 in December 2027, 6.12 and 6.18 in December 2028.

The version number is not enough to answer the third. The kernel CNA only assigns CVEs to the versions the stable team supports, leaves the decision on applicability to the user and recommends applying full stable releases rather than individual fixes. The “affected” ranges in the records therefore do not describe a vendor kernel outside those branches. And backports scramble the numbering in both directions. The MM flaw only exists in mainline from 7.0, but a backport carried it into 6.18, from 6.18.21 to 6.18.49, and into 6.19, from 6.19.11; RHEL 9, with a 5.14 base kernel, had the Futex flaw, which upstream has only existed since 6.17. The SBOM from article 01 should record the branch and the patches applied, and the status of each CVE in the product can be communicated in VEX.

When the branch’s end of life falls before the end of the support period the manufacturer declares, another route is needed. The Linux Foundation’s Civil Infrastructure Platform maintains SLTS kernels for industrial use, with end of life projected for January 2031 (5.10), August 2033 (6.1) and June 2035 (6.12). The alternatives are to move to another branch during the product’s life or to contract that support from the vendor.

Python: ssl for the cloud connection, tarfile for updates

Two Python modules bear directly on what a device does on its own: ssl, underneath many cloud connections, and tarfile, which many update agents use to unpack packages.

Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 and 3.14.8 came out between 30 Sep and 1 Oct 2026. Python 3.10.22, of 1 Oct, is the last of the 3.10 branch, which reached end of life that day and will get no more security fixes. On the ssl side, two fixes matter to manufacturers.

CVE-2026-19553 affects clients. SSLContext.wrap_bio() did not require server_hostname when check_hostname was enabled, and in that case the check of the name in the certificate was silently skipped; code that passes a non-empty server_hostname is not affected. The PSF rates it high, with a CVSS 4.0 score of 7.6. The fix is not the same in every branch: in 3.10, 3.11 and 3.12, the omission now only triggers a deprecation warning, for compatibility, and only from 3.13 onwards does it raise an error. In those branches, updating Python is not enough. The official mitigation is to always pass a valid server_hostname to wrap_bio(), asyncio.create_connection() and loop.start_tls().

CVE-2026-19445 affects servers. A remote, unauthenticated TLS client can crash the process, or lead it to use memory that has already been freed, when the sni_callback switches context and nothing else keeps the original context alive. The PSF rates it critical, with a CVSS 4.0 score of 9.2. It matters, for example, to a device that serves a local HTTPS interface from Python, picks the certificate by the requested name with sni_callback, and creates the context with that callback on each connection, or replaces it while connections are open. A server that wraps the listening socket with that context is not affected. The mitigation is to keep a reference to each SSLContext that sets sni_callback for the whole life of the server.

On the tarfile side, the same releases closed three flaws in the extraction filters (CVE-2026-82049, CVE-2026-87910 and CVE-2026-19672); CVE-2026-87910 only reached the 3.14 branch with 3.14.9, of 21 Oct. On 22 Oct, the PSF announced one more, CVE-2026-114583: the tar filter could be bypassed by crafted link entries in a malicious archive, which could then write files outside the destination directory, within the process’s permissions. The PSF rates it medium severity, with a CVSS 4.0 score of 6.9. On 23 Oct, the fix had been merged into the main branch and the 3.15 and 3.14 branches, the backports to 3.13, 3.12 and 3.11 were awaiting merge, and no released version included it. Python 3.10 is not on the list.

The official documentation recommends the data filter. Since 3.14 it has been the default filter; before that, extraction fully trusted the archive, and for 3.13 and earlier the recommendation is to set filter='data' explicitly. The data filter itself had bypasses fixed this year, in June (CVE-2026-7774, the equivalent of CVE-2026-114583 in the data filter) and in these releases, and it only protects in a version that already includes those fixes. No filter blocks every dangerous feature, and archives from untrusted sources should not be extracted without inspection. In an update agent, this translates into an order of operations: verify the package signature before extracting anything at all. That way, whoever lacks the signing key cannot get an archive of their own to the code that extracts it.

The branch matters too. Python 3.10 no longer receives fixes of any kind. Python 3.11 gets security fixes until October 2027, 3.12 until October 2028 and 3.13 until October 2029, and in security-only branches releases are, as a rule, source-only. A product that declares in 2026 a five-year support period with Python 3.11 inside will have to change branch midway, or take on the fixes itself.

The certificates built into the firmware

On 17 Oct 2026, a community researcher reported to the root programmes of Apple, Google, Microsoft and Mozilla that the private keys of eight eMudhra intermediate certificate authorities had been generated with insufficient randomness; eMudhra was informed the same day. According to Google, this allowed anyone to forge trusted HTTPS certificates for any site, as far as clients that still trusted those intermediates were concerned. Six are intended for TLS and two for code signing. Chrome and Firefox blocked them the same day through their own mechanisms (CRLSet and OneCRL), and eMudhra revoked all eight on 18 Oct.

According to eMudhra, only one was in production and none issued end-entity certificates; the company says it knows of no indication that the weak keys were recovered or exploited before disclosure. Up to 19 Oct, according to Mozilla, the Certificate Transparency logs also showed no certificates from these intermediates. The incident page points out that the keys could be recovered from the certificates ever since these were created, in April 2025, and that it is not known whether anyone did so against clients that do not require Certificate Transparency. Mozilla considers abuse of the keys likely in the short term. Browsers require Certificate Transparency. Many clients outside browsers neither require it nor check revocation, and for those, protection arrives with a software update.

That update is the removal of trust from the store. NSS 3.131.1, of 20 Oct, removes three emSign roots, one of them because of the incident: “emSign ECC Root CA - G3”, to which the intermediates chain through a cross-signature (they were issued by two other eMudhra roots, which Mozilla does not include), and Chrome removes it from its store in a release scheduled for 27 Oct. To those who maintain stores with no way of distrusting specific intermediates, Mozilla recommends considering the removal of three roots (AAA Certificate Services, emSign Root TLS CA - G3 and emSign ECC Root CA - G3), even if some legitimate servers become unreachable. On 20 Oct, Debian (DSA-6572-1) blocked emSign ECC Root CA - G3 and AAA Certificate Services in ca-certificates, and Ubuntu removed emSign ECC Root CA - G3 and, in releases 14.04 to 20.04, also AAA, which was no longer in releases 22.04 and later. Red Hat published bulletin RHSB-2026-012 on 21 Oct and an update for RHEL 10 on 22 Oct (RHSA-2026:88455).

Language ecosystems bring their own stores, and each one needed a fix:

  • Python. certifi 2026.10.19 and pip 26.2.2 came out on 20 Oct, and Python 3.15.1, 3.14.9 and 3.13.17, of 21 Oct, now include that pip. Christian Heimes, a CPython core developer, points out that pip always loads the certifi it bundles, in addition to the system store, so removing trust only at operating-system level is not enough. Python 3.11 and 3.12 will not receive the new pip; in those branches it is updated by hand, environment by environment. CPython is also preparing, as defence in depth, a blocklist of these intermediates’ keys in the ssl module, with a backport requested down to 3.11; on 23 Oct it had not yet been merged.
  • Node.js. The security releases of 21 Oct, covered in article 09, include the update of the root certificates.
  • Go. Go 1.27.3 and 1.26.10 add to crypto/x509 a blocklist for these intermediates (CVE-2026-111943). Because the list lives in the standard library, a Go binary only gets it when it is recompiled.

For manufacturers, the concrete question is where the certificate stores built into the firmware come from and how they are updated. The emSign roots entered Debian’s ca-certificates in 2020, and the certifi advisory lists every version since 2019 as affected, so firmware built since then with a store derived from Mozilla’s probably carries the root that has now been removed. The eight intermediates also carry a Sectigo cross-signature from May 2025, under the AAA Certificate Services root, which sat for many years in the stores derived from Mozilla’s and remains in Apple’s and Microsoft’s. Firmware with one of those stores that does not check revocation probably trusts these keys, whenever it was built. In an old store, removing only emSign ECC Root CA - G3 is not enough: either move to the whole current store, or remove the three roots Mozilla points to. If the store only changes with a new firmware image, each root removal requires a full update cycle.

The store goes into the SBOM as a component, with its origin and date, and needs an update path, either its own or inside each OTA update. On the manufacturer’s own cloud connection, the device can trust only the authorities that connection uses, provided there is a plan for replacing them; an incident at an authority the connection does not use then no longer weighs on it. That leaves the build side: the PSF recommends rebuilding container images without layer caching and updating pip in every virtual environment, which also applies to the images that build the firmware.

Does any of this have to be notified?

Article 14 of the CRA requires two things to be notified: actively exploited vulnerabilities contained in the product (paragraph 1) and severe incidents having an impact on the security of the product (paragraph 3). The product includes its remote data processing solutions (Article 3(1)), and the Commission guidance of 27 July 2026, C(2026) 5252, which is non-binding, applies Article 14 to them as well (point 178). The same document leaves CI/CD pipelines and the distribution of security updates outside that concept (point 182). A compromise of the build or update servers capable of introducing malicious code into the product is nonetheless a severe incident (Article 14(5)(b)), with an early warning notification within 24 hours and an incident notification within 72 hours.

As of 23 Oct 2026, none of the CVEs cited in this article is in CISA’s KEV catalogue (version of 21 Oct). In the PwnEscape record, CISA’s assessment of 16 Oct indicates no known exploitation. Red Hat writes that it is tracking the flaw as a KEV case of active exploitation, without naming the source and with no entry in CISA’s catalogue. The demonstration against production sandboxes that Vercel reports was carried out in the challenge Vercel itself launched, with authorisation. The CRA only considers a vulnerability actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Article 3(42)), and we found no primary source reporting exploitation of that kind. For a product that fits the scenario described in the PwnEscape section, that discrepancy is a matter for triage.

The public Infinity Core exploits show that the flaws can be exploited, but they are not, in themselves, evidence that a malicious actor has exploited them. In the eMudhra case, the company says it knows of no indication of exploitation before disclosure, Mozilla considers abuse of the keys likely in the short term, and the incident page says it is not known whether there was exploitation against clients that do not require Certificate Transparency.

According to the same guidance (point 218), if a component’s vulnerable code is not reachable in the product, or there has been no exploitation in it, that manufacturer has no mandatory report to make. In that case, the manufacturer can still notify voluntarily (Article 15). For triage, exploitation of the same component in other systems is a signal to take into account. If triage concludes that there has been exploitation in the product, the Article 14 timeline opens: early warning notification within 24 hours, vulnerability notification within 72 hours and final report, through the single reporting platform. Article 02 describes the circuit.

A note on rigour. The exploitation status described here is what the cited sources indicated on 23 Oct 2026, and it may change. The C(2026) 5252 guidance is non-binding. The decision on whether there has been active exploitation in a specific product rests with the manufacturer, based on its own triage, and this article replaces neither that assessment nor legal advice.

Where to start

This week, the SBOM has to answer three questions: which kernel is on the device, from which branch and with which patches; which Python and which pip, on the device and in the build images; which certificate stores are in the firmware (the system one and the embedded ones, such as the certifi of Python applications, the Node.js one or the blocklist compiled into Go binaries), and from when. If the SBOM does not have these answers yet, completing it is the first step.

Then, for each fix that applies, the question is how it reaches the devices already sold. A new kernel from the vendor, a fixed Python or an updated certificate store all need the same route: a signed update, over the air or local, available throughout the declared support period. The SoC vendor gets the four questions from the kernel section, in writing and dated.

In most of this month’s cases, the upstream fix already exists. The missing stretch, between the manufacturer and the device, is one only the manufacturer can build.

Sources