Severity Daily

IT and AI security incidents, checked against the primary source

Tag: disputed severity

  • MediaTek grades its bulletin on CVSS v3.1 — then rates three flaws High that its own CVSS scores put at Medium

    MediaTek grades its bulletin on CVSS v3.1 — then rates three flaws High that its own CVSS scores put at Medium

    MediaTek’s September bulletin says its severity ratings come from CVSS v3.1. Three of the five flaws it labels High carry MediaTek’s own CVSS v3.1 scores of 5.5, 5.3 and 5.3 — Medium — and rank below four it labels Medium.

    What happened

    MediaTek published its September 2026 Product Security Bulletin on Monday, September 7, 2026, covering 18 CVEs across its chipset portfolio. NVD carried the matching records the same day, timestamped 2:17 a.m. UTC, all from [email protected] — MediaTek is its own CNA, so the bulletin and the CVE records are two publications by the same organization on the same day about the same bugs.

    The bulletin states how it grades: “The severity of the identified vulnerabilities was conducted based on the Common Vulnerability Scoring System version 3.1 (CVSS v3.1).” It also says that “Device OEMs have been notified of all the issues and the corresponding security patches for at least two months before publication,” and that “At this time, we are not aware of any active exploitation of these vulnerabilities in the wild.”

    Five entries carry the word High in the bulletin’s severity column: CVE-2026-20500, CVE-2026-20501, CVE-2026-20502, CVE-2026-20503 and CVE-2026-20504. The other thirteen are labeled Medium.

    Now the scores MediaTek assigned to those same CVEs as CNA, read from the NVD records:

    • CVE-2026-20500 — bulletin: High. CVSS v3.1 base score 5.5, MEDIUM, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. “In Modem, there is a possible system crash due to improper input validation. This could lead to local denial of service with User execution privileges needed.”
    • CVE-2026-20503 — bulletin: High. CVSS v3.1 base score 5.3, MEDIUM, vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. “In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed.”
    • CVE-2026-20504 — bulletin: High. CVSS v3.1 base score 5.3, MEDIUM, same vector, same description.

    Against four the bulletin calls Medium:

    • CVE-2026-20506 and CVE-2026-20507 — Audio HAL use-after-free, CVSS v3.1 6.7, CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, CWE-416.
    • CVE-2026-20508 — Power HAL type confusion, 6.7, same vector.
    • CVE-2026-20517 — geniezone use-after-free, 6.7, same vector, CWE-416.

    Under the CVSS v3.1 qualitative scale, 4.0 through 6.9 is Medium and 7.0 through 8.9 is High. So three of the five items MediaTek calls High are Medium by the very standard the bulletin names, and every one of them scores below four items MediaTek calls Medium. Only CVE-2026-20501 and CVE-2026-20502, the two vdec heap and out-of-bounds write bugs, cross 7.0; both scored 8.4 in the batch retrieval used here.

    One more defect in the same batch. CVE-2026-20500 is classified CWE-295, Improper Certificate Validation. Its description is a modem crash from improper input validation with no certificate, no TLS and no trust decision anywhere in it. CWE-20 or CWE-1284 is the obvious fit. The other records in the batch are classified sensibly — CWE-617 for the reachable assertions, CWE-416 for the use-after-frees — which makes this one look like a single slip rather than a systematic problem.

    None of the 18 records carries CPE data. All were in Received status at the time of reading, which means no NVD analysis, no configuration block, and nothing for a version-matching scanner to bind to.

    Why it matters

    A vendor advisory that carries two severity systems is common. Google’s Android Security Bulletin has long rated a remote denial of service on the modem above a local privilege escalation, on the reasonable view that something an attacker reaches over the air matters more than something requiring code already running as System. On that rubric, MediaTek’s word ordering is defensible and arguably better calibrated than the arithmetic: CVE-2026-20503 needs only that a handset attach to a rogue base station, while CVE-2026-20517 needs the attacker to hold System privilege first. CVSS v3.1 punishes AV:A combined with AC:H severely and rewards C:H/I:H/A:H generously even behind PR:H, and that is how a bug requiring existing System access outscores one requiring only radio proximity.

    That reconciliation is available to a reader who knows the Android rubric exists. It is not available from this document, because this document says the severity ratings were “conducted based on” CVSS v3.1. If the bulletin said it graded on operational risk, or on Android’s severity classifications, the word and the number would be two measurements and a reader could hold both. Saying the word is the number, and then publishing a number that contradicts it, leaves no way to reconcile them from the primary source. That is what makes this a record problem rather than a methodology disagreement.

    The practical consequence is that triage splits by tooling. A person reading the bulletin escalates the three modem flaws and defers the HAL bugs. A pipeline ingesting the CVE feed and sorting on CVSS does the exact opposite, because 6.7 sorts above 5.3. Both are following MediaTek. Neither can tell from MediaTek’s own material that the other exists, and in an organization running both, the same 18 CVEs produce two different priority orders from one vendor’s publications.

    Then there is the part that makes the argument mostly theoretical. With no CPE on any record, none of these will match a device inventory automatically. There is no fixed firmware version in the bulletin to check against — there cannot be, because MediaTek does not ship firmware to handsets. The patches went to OEMs “at least two months before publication,” and whether they reached a given device depends on that OEM’s release schedule and on how long the model has been in support. For a fleet manager, the actionable artifact is not the CVE at all. It is the Android security patch level on the handset, and the bulletin does not say which patch level carries these fixes.

    This is the recurring shape of silicon-vendor advisories, and it is worth naming plainly: the entity that knows the bug has no relationship with the device owner, the entity with that relationship did not find the bug, and the record that is supposed to connect them carries no version data. The severity disagreement is a symptom. Even resolved perfectly, it would not tell anyone which phones on their network are still exposed.

    What to do

    Triage on the vector, not the word or the score. For this batch the split is clean. CVE-2026-20500, CVE-2026-20503 and CVE-2026-20504 are availability-only modem crashes: no confidentiality or integrity impact, and the two remote ones require the device to attach to an attacker-controlled base station. CVE-2026-20506, CVE-2026-20507, CVE-2026-20508 and CVE-2026-20517 are full-impact local escalations that require System privilege as a precondition — serious as the second stage of a chain, useless as a first stage. Neither group is remote pre-authentication code execution. Nothing here warrants an emergency.

    Track the patch level, not the CVE. Set and enforce a minimum Android security patch level through your MDM and measure your fleet against it. That is the only control that reaches these bugs. Devices past their OEM support window will not receive these fixes at all, and no scanner will tell you so.

    If you filter CVE feeds by CWE, do not trust CWE-295 on CVE-2026-20500. A rule that routes certificate-validation weaknesses to your PKI or transport owners will misfile a modem input-validation crash.

    If you build products on these chipsets, the chipset lists matter more than the severities. CVE-2026-20501 and CVE-2026-20502 name roughly 50 part numbers each and CVE-2026-20503 names more than 55, spanning phones, tablets and smart-display silicon. CVE-2026-20516, the MiracastService privilege escalation, is scoped entirely to MT5xxx and MT9xxx television parts — a reminder that a MediaTek bulletin is not only a handset document.

    Sourcing note

    Checked: MediaTek’s September 2026 Product Security Bulletin, read directly, twice, with the second read directed specifically at the severity column to confirm the printed words for CVE-2026-20500, 20503, 20504, 20506, 20507, 20508 and 20517. The quoted sentences on severity methodology, OEM notification and exploitation are from that bulletin. The CVSS scores, vectors, CWE classifications and Received status for CVE-2026-20500, 20503, 20504, 20506 and 20517 were each read from the NVD API record for that CVE individually, and the absence of CPE data was confirmed by a query that asked for it explicitly rather than by a general summary.

    Could not reach: The individual NVD records for CVE-2026-20501 and CVE-2026-20502 could not be re-read — the API began returning HTTP 429 partway through this run. Their base scores of 8.4 come from a single bulk NVD query covering the day’s publications and have not been independently re-confirmed. Nothing in this story’s central finding depends on them; they are the two entries where the bulletin’s word and the score agree.

    Unresolved: MediaTek has not been asked why the bulletin’s severity words diverge from its own CVSS scores, and the bulletin offers no second rubric that would explain it. The Android Security Bulletin rubric is offered here as the most plausible explanation, not as MediaTek’s stated reason. Which Android security patch level carries these fixes is not stated in the bulletin and could not be determined. Whether NVD will later add CPE data, or whether CISA’s ADP channel will add its own scores as it has on other unscored records, is unknown at the time of writing.

  • h3 scored its own cookie-loop hang as Moderate; the CVE published six months later says High, and the whole gap is one availability metric

    h3 scored its own cookie-loop hang as Moderate; the CVE published six months later says High, and the whole gap is one availability metric

    GitHub’s advisory database still shows “No known CVE” for the flaw CVE-2026-86250 describes, and every affected version — along with the only fix — is a pre-release build.

    What happened

    On September 6, 2026, VulnCheck published CVE-2026-86250 against h3, the HTTP server framework maintained by the h3js project and used as the request layer under Nitro and Nuxt. The NVD record went live at 2026-09-06T12:17:15.767 and describes the flaw this way:

    “h3 versions before 2.0.1-rc.18 fail to validate the chunk count parsed from user-controlled cookie values in setChunkedCookie() and deleteChunkedCookie() functions. Attackers can send a crafted cookie header with an extremely large chunk count to trigger an O(n²) cleanup loop that hangs the server process.”

    VulnCheck rates it High: 7.5 on CVSS 3.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, and 8.7 on CVSS 4.0. The weakness is CWE-400, uncontrolled resource consumption. Affected versions are >= 2.0.0-beta.4, < 2.0.1-rc.18; the fix is 2.0.1-rc.18.

    None of that is new. The h3 project published its own advisory for the same flaw, GHSA-q5pr-72pq-83v3, on March 21, 2026, reviewed and last updated March 23. Same functions, same version ranges, same fix, same CWE, same reporter — credited to @offset in both records.

    What differs is the score. The h3 advisory rates the flaw Moderate, at 5.3, on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.

    Set the two CVSS 3.1 vectors side by side and they are identical in seven of eight metrics. Attack vector network, attack complexity low, no privileges, no user interaction, scope unchanged, no confidentiality impact, no integrity impact. The only difference is the last one: the project wrote A:L, and VulnCheck wrote A:H. That single letter is the entire 2.2-point gap, and on CVSS 4.0 it is the difference between a number that would not have been calculated at all and 8.7.

    The h3 advisory’s own text describes the impact. It states that “an unauthenticated attacker can send a single request with a crafted cookie header (e.g., Cookie: h3=__chunked__999999) to any endpoint using sessions, causing the server to enter an O(n²) loop that hangs the process.” It walks through the mechanism: the chunk count is parsed at src/utils/cookie.ts with, in the advisory’s own annotation, “no upper bound check — attacker controls this value,” and the cleanup path runs one deleteCookie per chunk, each of which “scans ALL existing set-cookie headers.” At the example value it puts the result at roughly 1012 operations. It adds that “session usage is extremely common in web applications.”

    As of retrieval, GitHub’s advisory database page for GHSA-q5pr-72pq-83v3 lists “No known CVE.” VulnCheck’s advisory for CVE-2026-86250 explicitly references the GHSA. The link runs one way.

    Why it matters

    Start with which score is right, because the advisory that carries the lower one contains the evidence against it.

    CVSS 3.1 defines A:L as reduced performance or interruptions in resource availability, with the attacker unable to completely deny service. A:H is a total loss of availability, or a sustained denial the attacker controls. A single unauthenticated request that hangs the process is the second thing. The h3 advisory says “hangs the process” in its own summary sentence. It scored its flaw against a definition its own description does not meet.

    This is worth being fair about. Self-scoring is genuinely hard, and maintainers do it more honestly than almost anyone — the alternative is a flaw nobody documents at all. The specific trap here is a common one: the availability metric reads intuitively like a question about how degraded the service gets, when the specification is asking whether the attacker can take it away entirely. A hang feels less severe than a crash. Under CVSS it is not; a hung process serving nothing is a total loss of availability, and it does not restart itself the way a crashed one under a supervisor does.

    The consequence is not academic. A 5.3 and a 7.5 land in different buckets in almost every process built on top of these records. Dependency scanners default to alerting on High and above. Vulnerability management policies set different remediation clocks at Moderate. A team that saw the h3 advisory in March, read Moderate, and put it in the backlog behind the Highs made that decision on a number that the same advisory’s prose contradicts. Nothing about the flaw changed between March and September. The published severity did.

    Then there is the six-month gap, and what it did to visibility. From March 21 to September 6, this flaw existed in exactly one place: GitHub’s advisory database, with no CVE attached. Software composition analysis tools that consume the GitHub advisory feed saw it. Tools keyed to NVD saw nothing, because there was nothing to see. Those two populations are both large, and for 169 days they had different pictures of the same dependency. Now both have a record, and the records disagree about how bad it is, and the older of the two still says no CVE exists.

    One scope limit deserves stating plainly, because it cuts against alarm and it explains part of what happened. Every affected version is a pre-release. The range starts at 2.0.0-beta.4 and ends before 2.0.1-rc.18; there is no stable h3 v2 release in it. The h3 v1 line, which is what a great many Nuxt and Nitro deployments are actually running today, is not in the affected range at all. So the real population here is teams who moved to h3 v2 early — a smaller group than “everyone downstream of Nuxt,” and one that has, on the whole, opted into some instability.

    But the fix is a pre-release too, and that is the part that bites. 2.0.1-rc.18 is the only version that closes this, and a release candidate is precisely what many organizations’ dependency policies forbid in production. The remediation and the prohibition point in opposite directions. If your policy says no pre-release dependencies and your lockfile already contains an h3 v2 beta, the policy was violated before the vulnerability existed, and the only compliant path forward is backward — to v1.

    What to do

    Check whether you have h3 v2 anywhere, directly or transitively: npm ls h3 across your workspaces, and grep lockfiles for [email protected].. Anything on the v1 line is outside the affected range and needs no action for this.

    If you find a v2 build below 2.0.1-rc.18, move to 2.0.1-rc.18 or later. That is the only fix either record names. If a pre-release dependency policy blocks that, the honest options are a documented exception or a move back to h3 v1; there is no stable v2 build that resolves this.

    For an interim control while you schedule the upgrade, the attack has a distinctive signature at the edge. The trigger is a cookie whose value matches the chunked-cookie marker followed by a chunk count — the advisory’s example is h3=__chunked__999999. A reverse proxy or WAF rule that rejects requests carrying a chunked-cookie value with an implausibly large count will stop this before it reaches the session handler. Pick the bound from your own application: real chunked cookies exist to carry a session across a handful of cookie-sized pieces, not a million.

    The broader habit worth taking from this: when a project advisory and a CVE record disagree on severity, read the advisory’s description before you trust either number. Here the description settles the question, and it was sitting in the lower-scored record the whole time.

    Sourcing note

    Checked directly: the NVD record for CVE-2026-86250 (published 2026-09-06T12:17:15.767) for the description quoted above, both CVSS vectors, the CWE, and the affected and fixed version ranges; GHSA-q5pr-72pq-83v3, retrieved twice at two different URLs — the project’s own security-advisories page and the github.com/advisories mirror — for the advisory text, the code annotations, the March 21, 2026 publication date with its March 23 review, the Moderate rating and the 5.3 vector, and the credit to @offset; and VulnCheck’s advisory page for CVE-2026-86250, which confirms the High rating, the 8.7 CVSS 4.0 score, a disclosure date of September 6, 2026, and an explicit reference back to the GHSA.

    The two GHSA retrievals agreed on every value used here. The “No known CVE” line is what the github.com/advisories mirror displayed at the time of retrieval; GitHub backfills CVE identifiers onto reviewed advisories on its own schedule, so that may resolve without anyone doing anything, and this story treats it as a lag rather than a defect.

    Unresolved: whether the h3 maintainers were consulted on the CVSS 3.1 vector VulnCheck assigned, and whether either party intends to revise. Neither record contains a rationale for its availability metric; the argument above is drawn from the CVSS 3.1 specification’s own definitions applied to the h3 advisory’s description, and it is this publication’s reading, not a statement by either party. The record carries no CISA KEV fields and no federal deadline. There is no indication of exploitation, and neither advisory claims any.