Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Flatpak

  • Two Monday deadlines outrank a day of nines and a seventeen-record batch

    Two Monday deadlines outrank a day of nines and a seventeen-record batch

    Eleven stories ran today, and the loudest of them were loud on the numbers: a 10.0, two 9.9s, a pair of 9.8s on a perimeter VPN appliance, and seventeen CVE records for one project landing in the same minute. None of that is what to deal with first. Two flaws already on CISA’s Known Exploited Vulnerabilities catalog come due Monday, September 14 — ConnectWise ScreenConnect and GitLab — and both carry BOD 26-04’s forensic-triage obligation, which means a federal agency has to remediate inside the window and also determine whether the asset was already compromised. That is about 48 hours, on the weekend, and it is the only thing on today’s wire with a clock attached. A 9.8 with a patch available can wait until Monday morning; these two cannot. The ScreenConnect item is also the one most likely to be misread: the flaw is in the client, not the server, so cloud-hosted customers told “no action is required” for their server still have to update every host client and access agent they run.

    The day had a thread, and it was GitLab. One patch release, September 10, produced three separate stories in eighteen hours, and the vendor supplied none of the new facts in any of them. Overnight, the CISA coordinator block attached to the NVD record marked exploitation “active” while GitLab’s own advisory said nothing about exploitation at all. By the afternoon the catalog itself carried Thursday’s addition and Monday’s deadline — a date this site declined to report twelve hours earlier and has since corrected on the story that got it wrong. And by evening the record for a second flaw in the same release, CVE-2026-87719, named the two things the release notes had left out: the entry condition is an authenticated user with Duo Chat access, not an administrator, and what they come away with is Advanced Search instance configurations and credentials.

    After the deadlines, the perimeter. Check Point’s two 9.8s let an unauthenticated attacker run code on a VPN appliance, and neither record names a fixed version — the boundary is a Jumbo Hotfix take number, and the Spark appliance line the advisories cover is missing from the records entirely. Frontegg SAML SSO accepts unsigned SAML responses at 9.8 with no fix at all, the plugin having been closed on WordPress.org on September 4. The Events Calendar took three releases to close two unauthenticated 9.8 remote code execution flaws on a plugin installed on more than 600,000 sites, and no changelog line says so.

    Below that, three records that describe a flaw better than they describe a remedy. AVideo’s seventeen all draw the affected line at the same git commit hash, with the last tagged release dating to April 2024. vLLM and Socket Firewall make an unflattering pair, because in both the thing that failed was the safeguard: a trust_remote_code flag that vanished into **kwargs, and a firewall that did not verify TLS to the registries it exists to police. Flatpak’s Critical sandbox escape waited 32 days for an identifier, and the one Flatpak CVE issued in the meantime was a different bug.

    Still open at the end of the day: NVD’s record for the GitLab 10.0 does not carry cisaExploitAdd or cisaActionDue, so the single most authoritative machine-readable source an operator is likely to query still does not say the flaw is on KEV with a deadline two days out. GitLab has said nothing about exploitation since the patch release. Frontegg has no fixed version to offer, AVideo has no release to upgrade to, and Check Point’s records still omit Spark.

  • Flatpak’s Critical sandbox escape waited 32 days for a CVE, and the one Flatpak CVE issued in between was a different flaw

    Flatpak’s Critical sandbox escape waited 32 days for a CVE, and the one Flatpak CVE issued in between was a different flaw

    For a month the upstream project called it Critical with no identifier attached, while the one Flatpak CVE published in that window described a different bug, scored it Medium, and listed only Red Hat packages as affected.

    What happened

    NVD published CVE-2026-90616 at 8:16 p.m. UTC on Saturday, September 12, 2026. The record is marked Received, MITRE is the assigning source, the weakness is CWE-61 — UNIX symbolic link following — and the only CVSS score attached is a secondary v3.1 figure of 7.4, High, from the vector CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The affected range is every Flatpak version before 1.18.1.

    The description, verbatim: “In Flatpak before 1.18.1, a malicious sandboxed app can obtain arbitrary read and write access to files on the host, which can be escalated to arbitrary code execution on the host, a different vulnerability than CVE-2026-76925. Flatpak creates a few app data directories (e.g., /var/cache, /var/data, /var/config, and /var/tmp) in every sandbox on every app launch where, in some cases, components of the path are attacker-controlled. Missing symlink protection can redirect the directories. Some of these directories are bind-mounted by Flatpak by passing the path (e.g., /home/user/.var/app/APP_ID/cache/tmp), which contains attacker-controlled directories (tmp) to bwrap –bind SRC DST. bwrap passes the path on to the kernel, which then follows symlinks. A malicious symlink can point to arbitrary locations on the host and it will become mounted inside the sandbox.”

    The clause that matters for anyone tracking this by identifier is the one in the middle: “a different vulnerability than CVE-2026-76925.” The record is going out of its way to say it is not the Flatpak CVE you may already have seen.

    The upstream advisory came first. GHSA-8688-9×26-hhxj, published by the Flatpak project on August 11, 2026, is titled “Flatpak sandbox escape with full host filesystem access.” GitHub shows its severity as Critical. It carries no CVSS vector and no score. Under impact it says: “A malicious sandboxed app can obtain arbitrary read and write access to files on the host, which can be escalated to arbitrary code execution on the host.” Under mitigations it says: “No known mitigation other than updating.” Affected versions are 1.18.0 and earlier; the patched version is 1.18.1. The fix is credited to commit 4780729, “run: Harden ensure_data_dir and /var setup against symlink attacks,” with two further commits adding a regression test and Steam compatibility coverage, and the advisory notes that long-term-support distributions need backports from the flatpak-1.16.x branch along with related libglnx changes. The report is credited to Ee Yang.

    In the CVE field, that advisory read: no known CVE, requested but not yet assigned. It stayed that way for thirty-two days.

    Meanwhile, a Flatpak CVE did appear. NVD published CVE-2026-76925 on September 4, 2026 at 10:17 p.m. UTC, last modified September 8. Its status is Awaiting Analysis. Its description is a different flaw entirely: “A flaw was found in Flatpak. A Time-of-check to time-of-use (TOCTOU) race condition exists in the org.freedesktop.Flatpak.SystemHelper component. This vulnerability occurs because a privileged chmod operation executes before the OSTree repository validation within the Deploy() function. An attacker can exploit this timing window to redirect symlinks to arbitrary files, potentially leading to unauthorized file manipulation or information disclosure.” It is CWE-367, scored 5.8 Medium from a secondary vector, and its references are Red Hat’s CVE page and a Red Hat Bugzilla entry. Its configuration data names Red Hat Enterprise Linux 7, 8, 9, and 10 flatpak packages.

    So between August 11 and September 12, the record contained one Flatpak vulnerability. It was the wrong one for anyone running Flatpak somewhere other than Red Hat Enterprise Linux, it described a privileged-helper race rather than a sandbox escape, and it was two and a half CVSS points below the severity the upstream project had assigned to the flaw it was not describing.

    The two records also disagree about who is affected in a way that is not a detail. CVE-2026-90616 states an upstream range: everything before 1.18.1. CVE-2026-76925 enumerates Red Hat packages. Both concern the same project. Only one of them would match a Fedora, Debian, Arch, or upstream-built Flatpak in a scanner keyed on configuration data.

    No source checked reports exploitation of either flaw, and neither CVE is in the Known Exploited Vulnerabilities catalog.

    Why it matters

    Flatpak is the sandbox. That is its entire proposition: an application ships with its own runtime and is confined, and the confinement is what lets a user install software from a third party without granting it the run of their home directory. A bug that turns a launched app into arbitrary host read and write does not degrade a security feature. It removes the product.

    The mechanism is worth understanding because it is not exotic. Flatpak creates a handful of per-application data directories on every launch. Some components of those paths are attacker-controlled, because they live under a directory the application itself owns. A symlink placed there redirects the path. Flatpak then hands the path to bwrap --bind, bwrap hands it to the kernel, and the kernel resolves symlinks the way kernels do. Nothing in that chain is broken. Each component behaves as documented. The escape lives in the assumption — held at the top of the chain and never restated at the bottom — that a path built from application-controlled components is a path and not a redirect. Sandbox setup code is full of that assumption, in every project that writes it, which is why the fix commit is titled hardening rather than a bug fix.

    The record problem is the more transferable lesson. Three documents now describe the security content of Flatpak 1.18.1, and they assign three different severities: the project says Critical, the CVE that finally describes the flaw says 7.4 High, and the CVE that was available during the entire gap says 5.8 Medium about something else. None of these is a lie. The project’s label reflects what an escape means. MITRE’s 7.4 reflects a vector with local access and high attack complexity. Red Hat’s 5.8 reflects a race in a privileged helper. They are three correct answers to three different questions, arriving at a reader who asked only one: should I upgrade?

    Consider how that period looked from inside a normal vulnerability-management process. An organization scanning hosts for CVE identifiers between August 11 and September 12 got one Flatpak hit, scored Medium, scoped to Red Hat. On a Fedora or Debian fleet, it got nothing. A patching policy that escalates on Critical and defers Medium would have deferred, correctly by its own rules, on a record that was not about the flaw it needed to know about. The upstream advisory was public the whole time, on GitHub, marked Critical, with a one-line remedy. The gap was not in disclosure. It was in the channel that most organizations actually read.

    This publication has now covered several of these in a short span, and the pattern is consistent enough to name: the fix ships, the advisory ships, and the identifier — the thing that machinery keys on — arrives weeks later, sometimes after a different identifier for a neighboring bug has already set an expectation about severity. An identifier is not a warning. It is an index entry. Treating the index as the alarm means being late by exactly the length of the indexing queue, and that queue is currently measured in weeks.

    What to do

    Update Flatpak to 1.18.1 or later. The upstream advisory states there is no mitigation other than updating, and the 7.4 on the new record should not change that reading; the project’s own Critical label is the one that describes the outcome.

    If you run a long-term-support distribution, check what your vendor actually shipped rather than what version string you have. The advisory says LTS branches need backports from flatpak-1.16.x plus related libglnx changes, which means a 1.16.x package can be either fixed or unfixed depending on whether your distribution took both. Verify against your distribution’s errata for commit 4780729 rather than against the version number alone.

    Do not treat CVE-2026-76925 as covering this. It is a different flaw, in a different component, with different affected data, and closing it does not close the sandbox escape.

    If your scanner reads NVD configuration data, re-scan your Flatpak hosts now. Records published in the last twenty-four hours are the first ones that will match a non-Red Hat installation.

    Sourcing note

    Checked: the NVD record for CVE-2026-90616, published at 8:16 p.m. UTC on September 12, 2026, vulnStatus Received, assigning source MITRE; the NVD record for CVE-2026-76925, published September 4 and last modified September 8, vulnStatus Awaiting Analysis; and the Flatpak project’s GitHub Security Advisory GHSA-8688-9×26-hhxj, published August 11, 2026, which is one of the two references CVE-2026-90616 cites. All quotations are reproduced from those records and that advisory. The Known Exploited Vulnerabilities catalog was read from the cisagov/kev-data GitHub mirror, catalog version 2026.09.11, because cisa.gov returns 403 to automated fetching; neither CVE appears in it. Could not reach: the oss-security list post of August 11, 2026, cited as the second reference on the new record, returned only its subject line, “Flatpak 1.18.1 fixes multiple vulnerabilities,” through the fetching available here, so the full announcement text and any further CVE list it carries have not been read. GitHub’s REST API returned 403, so commit dates were not independently confirmed and the commit identifiers come from the advisory. Unresolved: the upstream advisory assigns no CVSS vector, so the Critical label cannot be compared numerically with MITRE’s 7.4; no reachable source explains the thirty-two-day interval between the advisory and the identifier; and no source checked reports exploitation.