The Cyber Resilience Act for VS Code extension authors, on the Marketplace and Open VSX
You publish a Visual Studio Code extension, on the Microsoft Marketplace, on Open VSX, or both. Since 11 September 2026 the EU Cyber Resilience Act asks some of you to report actively exploited vulnerabilities within 24 hours. Here is how to know whether that is you, what the two registries already expect, and what to put in place this week.
Are you a "manufacturer"?
The regulation applies to any product with digital elements made available on the EU market in the course of a commercial activity (Regulation (EU) 2024/2847, Article 2(1) and Article 3(1)). An extension is software. The only real question is the commercial activity.
The recitals give the test. Free and open-source software that is not monetised by its manufacturer is outside the regulation (recital 18). Monetised means, in practice: you charge a price, you sell a pro tier or a licence key, you sell paid support, you accept donations that go beyond covering your costs, or you process personal data beyond what security requires (recitals 18 and 19).
- Free extension by an individual, open-source licence, a sponsor link that covers hosting at best: outside the regulation. Keep it that way if you want to stay outside.
- Extension published by a company that sells a service (the client for your SaaS, your database, your AI assistant): part of the commercial activity even if free to install. Manufacturer.
- Freemium, free on the Marketplace, pro features unlocked by a licence key sold on your site (the Marketplace has no purchase button, only a "Free" or "Trial" label): the free version is part of a commercial activity. Manufacturer.
- Verified Publisher badge: it proves a domain and six months of account age, nothing about money. It changes nothing here.
- Open VSX: no fee, non-open-source licences accepted. The Publisher Agreement (v1.1, September 2025) makes you the distributor of your extension, solely responsible for it. Nothing found says Eclipse acts as open-source steward (Article 24) for third-party extensions. Your status depends on your activity, not on the registry.
A company that forks your extension and republishes it under its own publisher name becomes its manufacturer (Article 22).
What applies now, what applies in 2027
| From | Obligation | Article |
|---|---|---|
| 11 September 2026 | Report an actively exploited vulnerability in your extension: early warning within 24 hours, notification within 72 hours, final report within 14 days, through the ENISA single reporting platform. Same clock for a severe incident affecting the extension's security. | Article 14 |
| 11 December 2027 | Everything else: secure-by-design requirements, vulnerability handling (SBOM, coordinated disclosure policy, security updates for the support period), technical documentation, EU declaration of conformity, CE marking, and the fines. | Articles 13, 64, 71; Annexes I, V, VII |
"Actively exploited" means someone is using the flaw against real developer machines, not that a scanner found it. When a security vendor publishes "exploitation in the wild" for your extension, your 24 hours have started, or started earlier if you knew before they did.
Recent cases show the shape of it, all from before the obligation started. Code Spell Checker (CVE-2026-25931): a config file in a cloned repository ran code on open, fixed in 4.5.4, published 9 February 2026. Live Server (CVE-2025-65717, CVSS 9.1), Markdown Preview Enhanced (CVE-2025-65716) and Code Runner (CVE-2025-65715): file exfiltration and code execution, 125 million installs between them, and on 18 February 2026 only Microsoft's Live Preview had a fix. The public reports do not say whether any of these was exploited in the wild. Two supply-chain cases had no CVE: GlassWorm, 72 Open VSX extensions turned into carriers from 31 January 2026 through extensionPack, and a poisoned nrwl.angular-console 18.95.0, online for eleven minutes, behind the exfiltration of about 3,800 internal GitHub repositories on 18 to 20 May 2026. Under Article 14, a manufacturer whose extension is turned against its users this way has 24 hours from learning about it to file an early warning.
What the platforms already ask
- Visual Studio Marketplace: the Publisher Agreement (January 2019) says you, not Microsoft, are the provider of your extension and solely responsible for its security features. Microsoft scans every submission, signs every extension, and blocks a removed extension inside VS Code; in 2025 it removed 110 of the 136 it reviewed. It does not publish a fixing deadline.
- Open VSX: Eclipse does no review; you warrant that your extension contains no malicious code and that its data collection is fully disclosed. Since March 2026 every upload passes a mandatory pre-publish scan. Reports go to [email protected], acknowledged within two business days (policy of 9 April 2026).
- Neither registry files your Article 14 report for you. Microsoft has published no position on the CRA for extension authors; Eclipse's CRA material covers stewards and its own projects, not Open VSX publishers. The legal obligation stays yours.
Which class is your extension?
Most extensions are "default" products: self-assessment, no notified body. Annex III lists "important" products where a third-party assessment can be required unless you apply a harmonised standard. Two families matter for VS Code: password managers, and "software that searches for, removes or quarantines malicious software". An extension that stores and fills credentials or API keys, or one that scans a workspace for malware, should read Annex III, Class I, before assuming self-assessment.
This week, in order
- Decide your status with the free scope test. Eight questions, a written result with the article references. Free extension with no commercial activity: stop here, and write that decision down.
- Publish a security contact: a
SECURITY.mdin the repository, asecurity.txton your site, and a one-paragraph coordinated vulnerability disclosure policy. Annex I, Part II, point 5 will require it in 2027; today it is what makes a researcher write to you instead of to a blog. - Write the 24 h / 72 h procedure on one page: who watches the security vendors' feeds, who decides "exploited or not", who files on the ENISA platform, where the log is. Add one line for a stolen publisher token: revoke, unpublish, then report.
- Generate your SBOM. For an extension that means
package-lock.jsonor its yarn or pnpm equivalent, plus what your bundler ships inside the VSIX. The free scanner reads the lock file and flags anything on the CISA KEV list. - Fix the support period question. Article 13(8) asks for at least five years unless the product is expected to be used for less. Write the date in your README and on your pricing page.
The kit generates the thirteen documents behind these steps from one form, in English or French: CVD policy, security.txt, the reporting procedure with the ENISA-style templates, the support statement, the Annex I risk assessment and the Annex VII skeleton. Preview three of them in full before paying.
Where to ask
On microsoft/vscode-discussions, ask in Extension Development QnA and show your product only in Extension Show and Tell. The VS Code Dev Slack publishes no promotion rules, so keep the same split there. Stack Overflow takes technical questions under the vscode-extensions tag. For Open VSX, open an issue on eclipse-openvsx/openvsx, or write to [email protected] for legal questions. No CRA thread among extension authors was found. The Eclipse ORC working group, joined by OWASP in July 2026, runs the guides and maintainer round tables that cover the open-source questions.
Sources: Regulation (EU) 2024/2847 as published in the Official Journal; Visual Studio Marketplace Publisher Agreement (January 2019); Microsoft, Security and Trust in Visual Studio Marketplace (11 June 2025); VS Code documentation (15 September 2026); Open VSX Publisher Agreement v1.1 (September 2025), FAQ (8 May 2024) and Security Policy (9 April 2026); GlobeNewswire on Eclipse and OWASP (30 July 2026); SentinelOne on CVE-2026-25931 (9 February 2026); The Hacker News on four VS Code extensions (18 February 2026) and GlassWorm (14 March 2026); Phoenix Security on nrwl.angular-console (20 May 2026). Not legal advice.