What type of issue is this?
Question
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Target SharePoint environment
SharePoint Online
What browser(s) / client(s) have you tested
Additional environment details
Issue description
Following the official SPFx development environment setup documentation to install the required toolchain (@microsoft/heft, yo, @microsoft/generator-sharepoint), the yo package introduces a transitive dependency on locutus that carries a persistent series of critical-severity prototype pollution vulnerabilities.
| CVE |
Affected Range |
Fix Version |
Notes |
| CVE-2024-29016 |
>2.0.12 <2.0.39 |
2.0.39 |
Original prototype pollution via parse_str |
| CVE-2026-25521 |
(pre-3.x) |
partial |
Prompted further fix attempt |
| CVE-2026-33994 |
<3.0.25 |
3.0.25 |
Incomplete fix for CVE-2026-25521 — RegExp.prototype.test-based guard is itself pollutable |
At the time of writing, yo's dependency resolution pulls in a locutus version that falls within one or more of these vulnerable ranges. This appears to affect all recent published versions of yo: https://www.npmjs.com/package/yo?activeTab=versions. The Snyk advisory page for locutus (https://security.snyk.io/package/npm/locutus/versions) shows critical flags through at least 3.0.14.
Impact
In enterprise environments, outbound npm traffic is commonly routed through a security proxy that blocks installation of packages with known critical CVEs. This renders the SPFx toolchain setup completely non-functional in those environments — not due to a policy misconfiguration, but because the prerequisite packages themselves fail audit. Given the current threat landscape (Shai-Hulud worm, Chalk/Debug supply chain compromise, etc.), this proxy posture is increasingly the default, not the exception.
Steps to reproduce
npm install -g yo
npm audit
Observe critical vulnerability reported for locutus in the dependency tree.
Questions for the team
-
Is there a supported path to setting up an SPFx development environment that avoids yo entirely, or that constrains locutus to >=3.0.25 through a supported override mechanism? Should we consider implementing yo as a "devDependency", rather than a "global", this way we can implement "overrides"?
-
Should this be escalated upstream to the yo maintainers, and if so, is Microsoft in a position to engage them given the SPFx ecosystem's dependency on it?
-
Can Microsoft provide additional documentation, guidance, context, or framing for corporate security teams who are keen on preventing vulnerable packages that appear within their tooling ecosystem.
Note: I understand SPFx 1.23 is close, however, I believe yo will still be a tooling dependency there until the cli is made generally available. I assume at that point, the CLI will become the only necessary "global" install tool?
https://learn.microsoft.com/en-us/sharepoint/dev/spfx/release-1.23#preview-of-new-spfx-cli-and-open-sourced-templates
What type of issue is this?
Question
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Target SharePoint environment
SharePoint Online
What browser(s) / client(s) have you tested
Additional environment details
Issue description
Following the official SPFx development environment setup documentation to install the required toolchain (
@microsoft/heft,yo,@microsoft/generator-sharepoint), theyopackage introduces a transitive dependency onlocutusthat carries a persistent series of critical-severity prototype pollution vulnerabilities.>2.0.12 <2.0.392.0.39parse_str<3.0.253.0.25RegExp.prototype.test-based guard is itself pollutableAt the time of writing,
yo's dependency resolution pulls in alocutusversion that falls within one or more of these vulnerable ranges. This appears to affect all recent published versions ofyo: https://www.npmjs.com/package/yo?activeTab=versions. The Snyk advisory page for locutus (https://security.snyk.io/package/npm/locutus/versions) shows critical flags through at least3.0.14.Impact
In enterprise environments, outbound npm traffic is commonly routed through a security proxy that blocks installation of packages with known critical CVEs. This renders the SPFx toolchain setup completely non-functional in those environments — not due to a policy misconfiguration, but because the prerequisite packages themselves fail audit. Given the current threat landscape (Shai-Hulud worm, Chalk/Debug supply chain compromise, etc.), this proxy posture is increasingly the default, not the exception.
Steps to reproduce
Observe critical vulnerability reported for
locutusin the dependency tree.Questions for the team
Is there a supported path to setting up an SPFx development environment that avoids
yoentirely, or that constrainslocutusto>=3.0.25through a supported override mechanism? Should we consider implementing yo as a "devDependency", rather than a "global", this way we can implement "overrides"?Should this be escalated upstream to the
yomaintainers, and if so, is Microsoft in a position to engage them given the SPFx ecosystem's dependency on it?Can Microsoft provide additional documentation, guidance, context, or framing for corporate security teams who are keen on preventing vulnerable packages that appear within their tooling ecosystem.
Note: I understand SPFx 1.23 is close, however, I believe
yowill still be a tooling dependency there until the cli is made generally available. I assume at that point, the CLI will become the only necessary "global" install tool?https://learn.microsoft.com/en-us/sharepoint/dev/spfx/release-1.23#preview-of-new-spfx-cli-and-open-sourced-templates