GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

FKIE_CVE-2026-89321

Vulnerability from fkie_nvd - Published: 2026-09-14 09:17 - Updated: 2026-09-14 11:17
Severity
4.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Summary
Publishing limits the compressed size of a VSIX (ovsx.publishing.max-content-size, 512 MB by default) but nothing limited how large an entry becomes when opened. On the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opened the entry with ZipFile.getInputStream() and passed the decompressed stream to Files.copy(), which ran to the end of the stream without counting bytes written. The result was cached under java.io.tmpdir, and that cache evicted by entry count (150), not by size, so it placed no bound on disk usage. A publisher with access only to their own namespace could therefore upload a small, highly compressible VSIX and cause the server to write far larger files to the temp filesystem — repeating with different files or versions, since a repeat request is served from the cache. Impact observed: the temp filesystem filled; requests for files not already cached returned 500 with No space left on device; a failed extraction left a partial cache file that blocked later attempts at that path; publishing failed with Failed to read extension file. Metadata and already-cached files kept working, and the server did not stop. Triggering the extraction needs no authentication — only the upload does.
References
emo@eclipse.orghttps://github.com/eclipse-openvsx/openvsx/pull/2060
emo@eclipse.orghttps://github.com/eclipse-openvsx/openvsx/security/advisories/GHSA-h685-gqw7-fqw7
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Eclipse OpenVSX",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThan": "1.2.0",
              "status": "affected",
              "version": "0.20.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "emo@eclipse.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Publishing limits the compressed size of a VSIX (ovsx.publishing.max-content-size, 512 MB by default) but nothing limited how large an entry becomes when opened.\n\n\n\n\nOn the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opened the entry with ZipFile.getInputStream() and passed the decompressed stream to Files.copy(), which ran to the end of the stream without counting bytes written. The result was cached under java.io.tmpdir, and that cache evicted by entry count (150), not by size, so it placed no bound on disk usage.\n\n\n\n\nA publisher with access only to their own namespace could therefore upload a small, highly compressible VSIX and cause the server to write far larger files to the temp filesystem \u2014 repeating with different files or versions, since a repeat request is served from the cache.\n\n\n\n\nImpact observed: the temp filesystem filled; requests for files not already cached returned 500 with No space left on device; a failed extraction left a partial cache file that blocked later attempts at that path; publishing failed with Failed to read extension file. Metadata and already-cached files kept working, and the server did not stop.\n\n\n\n\nTriggering the extraction needs no authentication \u2014 only the upload does."
    }
  ],
  "id": "CVE-2026-89321",
  "lastModified": "2026-09-14T11:17:06.030",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "LOW",
          "baseScore": 4.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 1.4,
        "source": "emo@eclipse.org",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-89321",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-09-14T10:30:07.647299Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-09-14T09:17:01.797",
  "references": [
    {
      "source": "emo@eclipse.org",
      "url": "https://github.com/eclipse-openvsx/openvsx/pull/2060"
    },
    {
      "source": "emo@eclipse.org",
      "url": "https://github.com/eclipse-openvsx/openvsx/security/advisories/GHSA-h685-gqw7-fqw7"
    }
  ],
  "sourceIdentifier": "emo@eclipse.org",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-409"
        }
      ],
      "source": "emo@eclipse.org",
      "type": "Secondary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.