Severity Daily

IT and AI security incidents, checked against the primary source

Tag: TLS

  • Bilibili Desktop disables TLS verification process-wide and executes unsigned remote JavaScript through a 211-channel IPC bridge

    Bilibili Desktop disables TLS verification process-wide and executes unsigned remote JavaScript through a 211-channel IPC bridge

    The CVE published two days after the vendor was notified, the researcher’s own advisory still lists public disclosure as pending, and no fixed version is named.

    What happened

    On September 5, 2026, VulnCheck published CVE-2026-86185 against Bilibili Desktop, the Windows client for the Chinese video platform. The NVD record went live at 2026-09-05T12:16:49.240 and describes the flaw in one sentence:

    “Bilibili Desktop through 1.18.0 disables TLS certificate verification process-wide and executes unsigned remote JavaScript configuration without integrity checks. An attacker in an on-path network position can intercept configuration fetches, inject arbitrary JavaScript executed in the renderer with access to the privileged IPC bridge, and execute system commands or steal login credentials.”

    VulnCheck, acting as the assigning CNA, scores it 8.0 on CVSS 3.1 — AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — and 8.6 on CVSS 4.0. The AV:A is the important character in that string: this is an adjacent-network attack, not an internet-facing one. The weakness is recorded as CWE-295, improper certificate validation. Affected versions are given as “0 through 1.18.0” on Windows. No fixed version is named, in the NVD record or in VulnCheck’s own advisory.

    The mechanism comes from the researcher’s advisory, published by LeoWSY-hashblue and referenced by the CVE. It has two halves that only matter together.

    The first is a single line in the main-process entry point: process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0". That is Node.js’s global kill switch for certificate validation. Set there, every HTTPS request the application’s main process makes will accept any certificate, from anyone.

    The second is what the application does with one of those requests. On startup it fetches configuration from GET https://api.bilibili.com/x/elec-frontend/config/injectcode. The response, per the advisory, carries an enable flag, a set of url regular expressions, and a js field containing JavaScript source. There is no signature and no integrity check on that payload. On each in-app browser page load whose URL matches one of those patterns, the client passes the js content to executeJavaScript().

    The code that runs has access to window.biliBridgePc, which the advisory describes as a privileged IPC bridge exposing 211 registered channels, including the ability to launch executables. The chain, as the researcher lays it out: an attacker on the same network intercepts the config fetch, presents a self-signed certificate that the client accepts because verification is off, returns JavaScript of their choosing, and gets it executed with bridge access the next time the victim opens a page inside the app.

    The advisory’s own timeline reads: discovery on September 2, 2026; vendor notified on September 3 through the vulbox platform; CVE published by the VulnCheck CNA; public disclosure listed as to be determined, under a 90-day coordinated window. The repository holding it contains a single file, advisory.md, and the repository description calls it a “Sanitized advisory.” There is no exploit code in it.

    Why it matters

    Neither half of this would draw much attention alone. Shipping with certificate validation disabled is a bad bug that gets you traffic interception and credential theft on a hostile network — serious, bounded, and common enough that it rarely makes anyone’s morning reading. Fetching executable JavaScript from your own backend and running it in a privileged context is not a bug at all; it is a feature, and a widely used one. Hot-patching client behavior without shipping a release is exactly why an endpoint called injectcode exists.

    Put them in the same binary and the second feature inherits the first bug’s trust model. The channel that delivers code to the privileged context is now a channel anyone on the path can write to. That is the whole finding, and it is why the CWE assignment is worth arguing with. NVD carries CWE-295 and nothing else. The researcher’s own repository description names three: CWE-295, CWE-494 (download of code without integrity check), and CWE-94 (code injection). Only one of those three made it into the record. A team that filters advisories by weakness class — watching for code-injection and integrity-check failures in desktop software, as plenty do — will not see this one at all. It is filed under a certificate bug, and the certificate bug is the least interesting part.

    The NODE_TLS_REJECT_UNAUTHORIZED = "0" line deserves naming as a class. It is the desktop equivalent of verify=False in a Python script: a development-time workaround for a self-signed test certificate or a corporate proxy, set once to make an error go away, and then never removed. Node prints a warning to stderr when the variable is set. In a packaged Electron application, stderr goes nowhere anyone reads. The guardrail exists and is structurally invisible in exactly the deployment where it matters most.

    The 211 channels are the other number to sit with. The point of an IPC bridge in an Electron app is to expose a deliberately narrow set of main-process capabilities to renderer code that should not be trusted. A bridge with 211 channels on it, one of which starts processes, is not a narrow interface. It is a second API surface, and it means that any renderer-side code execution — from this bug, from a cross-site scripting flaw in embedded content, from anything — converts more or less directly into main-process code execution. The bridge size is a design decision made long before this CVE, and it is what turns “attacker runs JavaScript in a web view” into “attacker runs commands.”

    On urgency, be plain: there is no observed exploitation, and the attacker has to be on the network path. AV:A means a shared Wi-Fi network, a hotel or conference LAN, a compromised router, or an upstream hop. That is a real position and an unglamorous one to obtain, and it is not the internet. The realistic risk profile is a targeted user on an untrusted network, not a mass event.

    The disclosure sequence is its own small story. The vendor was notified on September 3. The CVE, carrying a description that states the mechanism plainly enough to reproduce from, was published on September 5 — two days later. The researcher’s advisory, written before that, still lists public disclosure as pending under a 90-day coordinated window. That window closed the moment the CVE went out, and the researcher did not close it. A third-party CNA publishing a record is under no obligation to hold to the reporting researcher’s embargo, and this is what it looks like when those two clocks disagree. Worth noting alongside it: the researcher’s timeline dates the CVE publication to September 6, while both NVD and VulnCheck’s own advisory page date it to September 5. Small, but it is the kind of drift that makes a disclosure timeline hard to audit later.

    What to do

    There is no patch. Treat every build through 1.18.0 as affected, and do not assume a later version fixes it — nothing in the record says one does.

    For most organizations reading this, the decision is inventory rather than remediation. Bilibili Desktop is a consumer media client; the question is whether it is installed on managed endpoints, and if so, why. Check your software inventory for it. Where it is present and needed, keep it off untrusted networks, and note that the trigger is opening a page in the app’s built-in browser — the risky action is in-app navigation, not merely having the client running.

    The transferable work is on your own applications, and it is cheap. Grep every Electron or Node build you ship for NODE_TLS_REJECT_UNAUTHORIZED, including in dependencies and build scripts; a match is a finding, not a style question. Then find every remote configuration endpoint your clients fetch, and ask of each one whether the response can contain code, and whether the response is signed. If the answer is yes and no in that order, you have this bug. Finally, count the channels on your IPC bridge. If the number surprises you, that is the audit.

    For detection, the config fetch itself is distinctive: requests to api.bilibili.com/x/elec-frontend/config/injectcode from a managed endpoint tell you the client is installed and reaching for remote code, regardless of whether anyone is tampering with the response.

    Sourcing note

    Checked directly: the NVD record for CVE-2026-86185 (published 2026-09-05T12:16:49.240, last modified the same), for the description quoted in full above, both CVSS vectors, the CWE assignment, the affected-version range, and the absence of a named fixed version; VulnCheck’s advisory page for the same CVE, for its disclosure date of September 5, 2026 and its credit to LeoWSY-hashblue; and the researcher’s advisory.md on GitHub for the technical mechanism, the environment variable, the configuration endpoint, the bridge channel count, and the disclosure timeline.

    The repository itself was checked for exploit code. It contains one file, advisory.md, and its description calls the contents sanitized. Nothing weaponized is published there as of this writing.

    Unresolved: whether Bilibili has responded to the September 3 report. The advisory records the notification and nothing after it, VulnCheck’s page states no vendor status, and this publication has no independent confirmation either way — so the absence of a vendor response here is an absence of information, not a finding about the vendor. Also unresolved is whether the flaw reaches the platform’s other desktop builds; the CVE names Windows, and neither source addresses macOS or Linux clients. The record carries no CISA KEV fields and there is no federal deadline attached.

    One conflict, stated as a conflict: the researcher’s timeline dates the CVE publication to September 6, 2026; NVD and VulnCheck both date it to September 5, 2026. This story uses September 5, because that is what the two primary records say.

  • June’s curl native-CA flaw drew a 9.1 from CISA; September’s wider version of it entered NVD with no score at all

    June’s curl native-CA flaw drew a 9.1 from CISA; September’s wider version of it entered NVD with no score at all

    curl shipped nine security fixes on September 2, 2026. NVD published the records four days later with no score, no CWE, and no version data — including the one that is a wider, older sibling of a June flaw CISA rated 9.1.

    What happened

    The curl project released curl 8.22.0 on Wednesday, September 2, 2026, closing nine advisories in curl and libcurl. The National Vulnerability Database published the corresponding CVE records on Sunday, September 6 — four days later, most of them stamped 6:17 p.m. UTC, with one arriving at 11:17 p.m. UTC. The NVD publication is the new development here; the fixes themselves are five days old.

    All nine records landed in the same condition. Each carries vulnStatus of Received, an empty metrics object, no weaknesses array, and no configurations block. No CVSS score, no CWE, and no CPE — which is the field a version-matching scanner needs in order to tell you that the curl in your build is affected.

    The item that matters most in the batch is CVE-2026-80231, which curl titles “Native CA store conn reuse” and rates Low. The advisory says the flaw makes libcurl “wrongly reuse an existing HTTPS connection setup for a given hostname even when using a different Native CA Store setting (CURLSSLOPT_NATIVE_CA) than when the connection was created.” It affects curl 7.71.0 through 8.21.0 on Windows and macOS, in both libcurl and the command-line tool, and is fixed in 8.22.0. Stanislav Fort of Aisle Research reported it on August 24, 2026; Daniel Stenberg wrote the patch.

    Ten weeks earlier, curl 8.21.0 shipped on June 24, 2026 carrying CVE-2026-11564, “Native CA trust persist” — also rated Low by curl, also about native platform trust surviving a configuration change, also on Apple and Windows builds. Its description: “An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer.” It affects curl 8.17.0 through 8.20.0. Filipe Casal of Trail of Bits reported that one.

    These are two distinct mechanisms, and the September advisory does not reference the June one. CVE-2026-11564 is about per-handle trust state: the handle keeps the platform store after the application hands it custom CA material. CVE-2026-80231 is about the connection pool’s match key: libcurl decides a pooled connection matches the current setup without checking whether the native CA setting is the same one that built it. Different code paths, same question — does libcurl’s reuse machinery notice when TLS trust changes underneath it — answered twice, ten weeks apart.

    The second answer covers far more ground than the first. CVE-2026-11564’s affected range begins at 8.17.0. CVE-2026-80231’s begins at 7.71.0, dozens of minor releases earlier, and it reaches the command-line tool, which the June flaw did not.

    The two records look nothing alike

    NVD published CVE-2026-11564 on July 3, 2026. It is now in Analyzed status. It carries CWE-295, Improper Certificate Validation. It carries a CPE configuration naming curl 8.17.0 through 8.20.x. And it carries a CVSS v3.1 base score of 9.1, CRITICAL, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

    That score is not NVD’s. The record holds exactly one CVSS entry, typed Secondary, from source 134c704f-9b21-4f2e-91b3-4a467353bcc0. NVD’s own source index resolves that UUID to CISA-ADP, the Authorized Data Publisher channel CISA runs to enrich records CNAs leave thin. There is no Primary entry from [email protected]. curl, as its own CNA, does not assign CVSS scores at all; it publishes a plain-English severity word instead. So the 9.1 on the June flaw is CISA’s reading of a bug curl called Low, and NVD has never scored it.

    CVE-2026-80231 has none of that. As of this writing it is a bare record: curl’s description, three reference links, and nothing else.

    The rest of the batch

    The other eight, all fixed in 8.22.0 and all published to NVD in the same bare state: CVE-2026-13608, an OpenLDAP SASL authentication bypass in which “an incomplete handshake sequence” is “misinterpreted as a successful cryptographic verification” (7.82.0 through 8.21.0, reported by Eunsoo Kim of Microsoft’s Autonomous Code Security team); CVE-2026-18924, an HTTP/2 Server Push use-after-free (7.44.0 through 8.21.0, Stephan Zeisberg of Security Research Labs); CVE-2026-19931, “Negotiate ambient user conn reuse,” the one item curl rates Medium, where blank Negotiate credentials are treated as ambient and a connection authenticated as one user is reused for another (7.64.1 through 8.21.0, Martin Dukek); CVE-2026-80229, a heap use-after-free when pooled OpenSSL 3 provider connections outlive the easy handles that created them (8.14.0 through 8.21.0); CVE-2026-80230, in which CURLOPT_PINNEDPUBLICKEY is not enforced on connections where no server certificate is presented (7.45.0 through 8.21.0); CVE-2026-80255, where a tab before the Secure attribute in a Set-Cookie header makes curl store the cookie without its Secure flag (8.13.0 through 8.21.0); CVE-2026-82208, where a wolfSSL CA cache hit reinstalls the cached trust store over one a CURLOPT_SSL_CTX_FUNCTION callback replaced (8.9.1 through 8.21.0); and CVE-2026-82209, where a cookie whose Domain matches a public suffix is stored with wildcard scope (7.46.0 through 8.21.0). Fort reported six of the nine.

    Why it matters

    Three parties have now expressed an opinion about how bad libcurl’s native-CA trust handling is, and they do not agree by four and a half points. curl says Low. CISA’s enrichment channel says 9.1 Critical. NVD says nothing, twice. A defender reading only the vendor advisory files this under housekeeping. A defender reading only the scanner output treats June’s as an emergency and September’s as nonexistent.

    That last case is the practical failure. An organization that patched curl in June did so because something in the pipeline surfaced a 9.1 against a matched CPE range. The September flaw is the same setting on the same platforms, it reaches many releases further back, and it additionally affects the command-line binary. It will surface nowhere, because the record has no CPE to match and no score to sort by. The team most likely to miss it is the one whose June response worked.

    curl’s position on CVSS is long-standing and openly argued: the project holds that a context-free base score misleads more than it informs, given how differently libcurl gets embedded. That is a deliberate editorial choice, not an oversight. The consequence is that a curl record is only ever as actionable as whatever enrichment arrives after it, and enrichment arrives on nobody’s schedule. June’s record got CISA-ADP within about a week. September’s has not got it in four days, and there is no published commitment that it will.

    Six of the nine came from one researcher at Aisle Research over a three-week window in August, and a seventh from a team Microsoft calls Autonomous Code Security. Machine-assisted auditing is producing curl findings faster than the record pipeline enriches them. The bottleneck for a defender has moved: the bugs are found and fixed promptly, and what fails is the metadata that would have told you which build to rebuild.

    There is also a pattern inside the nine that the individual Low ratings hide. Four of them — CVE-2026-80231, CVE-2026-82208, CVE-2026-80230, and CVE-2026-19931 — are the same shape: libcurl decides a connection or a trust store “matches the setup,” and the security-relevant parameter turns out not to be part of the match. Add June’s CVE-2026-11564 and that is five in two consecutive releases. Rated one at a time, each is a Low. Read together, they say libcurl’s reuse and caching layers are still discovering which of their inputs are security decisions.

    What to do

    Upgrade curl and libcurl to 8.22.0. That closes all nine.

    Do not wait for a scanner to raise it. These records carry no CPE, so version-matching tools will not fire on them for as long as they stay in Received status. Inventory by build instead: anything statically linking libcurl, any vendored copy in a container image, any language binding that ships its own libcurl. The command-line tool matters here too, unlike in June.

    Where you cannot upgrade quickly, curl publishes per-advisory workarounds. Set CURLOPT_FORBID_REUSE on transfers that use the native CA store (CVE-2026-80231), on transfers using blank Negotiate credentials (CVE-2026-19931), and on OpenSSL provider-based transfers (CVE-2026-80229). Avoid CURLOPT_SSL_CTX_FUNCTION with the wolfSSL backend (CVE-2026-82208). Disable HTTP/2 Server Push if you set CURLMOPT_PUSHFUNCTION (CVE-2026-18924). Stop using unencrypted ldap:// (CVE-2026-13608).

    If you patched for CVE-2026-11564 in June on the strength of the 9.1, check specifically for CVE-2026-80231 now. The June fix does not cover it, and your tooling is unlikely to tell you.

    Sourcing note

    Checked: curl’s advisory pages for all nine CVEs and for CVE-2026-11564; curl’s vuln.json database; the NVD REST API records for CVE-2026-80229, CVE-2026-80231, CVE-2026-82209, and CVE-2026-11564; and NVD’s source index, which resolves 134c704f-9b21-4f2e-91b3-4a467353bcc0 to CISA-ADP. Version ranges, severities, reporter credits, and timeline dates come from curl’s advisories. Record status, CVSS entries, CWE, and CPE presence come from the NVD API responses.

    Not reached: cisa.gov returns 403 to automated fetching, so CISA’s Vulnrichment repository was not read directly; the CISA-ADP attribution comes from NVD’s source index and the record’s own source field, which is NIST republishing CISA. NVD’s HTML detail pages render client-side and returned no content, so all NVD facts here are from the JSON API.

    Unresolved: whether CISA-ADP will enrich the September records, and on what timeline. The gap between curl’s Low and CISA’s 9.1 on CVE-2026-11564 is unexplained by either party — CISA-ADP entries carry no rationale, and curl does not publish CVSS. Whether NVD will ever assign a Primary score to either record is unknown; neither has one now.