We are preparing a Forge UI Kit application for Atlassian Marketplace submission and identified a high-severity security advisory, GHSA-c8x8-7fp4-3x9w, affecting prosemirror-view versions below 1.42.3.
Our application uses @forge/react and @forge/bridge. The dependency graph includes @atlaskit/editor-prosemirror@8.0.3 and 9.0.0, which require prosemirror-view@1.41.5.
We verified that the latest published @atlaskit/editor-prosemirror@9.0.0 still declares this exact dependency.
We attempted a root npm override to prosemirror-view@1.42.3. The fixed version installed successfully, but npm ls reported ELSPROBLEMS because the Atlaskit packages still require 1.41.5.
Our application does not directly import ProseMirror or provide rich-text editing functionality.
Could you clarify whether this dependency is included in Forge UI Kit application bundles, whether the advisory affects applications that do not expose ProseMirror editing, and whether Atlassian has a supported remediation or planned dependency update?
We would also appreciate guidance on whether this transitive dependency affects Marketplace security review.
For reference, the latest published @atlaskit/editor-prosemirror@9.0.0 still declares an exact dependency on prosemirror-view@1.41.5. An npm override to 1.42.3 installs successfully but results in npm ls reporting ELSPROBLEMS due to the exact dependency pin.
Hi @RobertLorusso,
The pin is real. On the 12.3.1 and 7.2.0 releases I installed, both packages reach @atlaskit/editor-prosemirror 9.0.0, which pins prosemirror-view at 1.41.5.
The advisory needs attacker HTML pasted into a ProseMirror editor. My esbuild bundle of a small UI Kit entry had no prosemirror code in it. I didn’t try the Forge CLI webpack build, so grep your own output.
The audit flag stays, though. The Marketplace security requirements say “An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities.” I’d raise an Ecosystem Support Request, since the pin is in Atlassian’s own packages.
The 1.42.3 override installed clean when I ran it on npm 11.12.1. I get ELSPROBLEMS from npm ls --all even without it, from react@18.3.1 under @atlaskit/modal-dialog. Is that the line you see?
Thanks, Mihai. This is helpful and aligns with what I’ve found.
I traced the dependency through Atlassian’s Forge packages as well, and my bundle inspection didn’t identify the vulnerable ProseMirror editor code. The remaining concern is the dependency audit finding and its potential impact on Marketplace eligibility.
I previously attempted an override but encountered dependency-tree issues. I’ll compare those results against the react@18.3.1 peer-dependency issue you mentioned. Did that issue persist after applying the override?
I’ll also look into raising an Ecosystem Support Request to clarify how Atlassian expects developers to handle security findings originating from its own pinned dependencies.
Appreciate you taking the time to reproduce this.
@RLorusso yes, it persisted.
This morning I installed @forge/react 12.3.1 again in two clean folders, one with the prosemirror-view 1.42.3 override and one without. In both I installed @forge/bridge 7.2.0 as well. I used npm 11.12.1.
Both npm ls --all runs end in ELSPROBLEMS on one invalid entry, react 18.3.1. Two peers reject it: react-scrolllock under @atlaskit/modal-dialog wants ^16.3.0, and @atlaskit/analytics-next-stable-react-context under @atlaskit/analytics-next wants ^16.8.0. Both arrive through @atlaskit/forge-react-types. The override doesn’t touch that.
With the override, every prosemirror-view in the tree resolves to 1.42.3 and none is flagged invalid. npm audit goes from 8 high to 0. Same on the 12.4.0 and 7.2.1 releases that came out today.
A react line in your ELSPROBLEMS predates the override. If yours names prosemirror-view, post it, because that one doesn’t show up here.
Thanks, Mihai (that was me in both, running two accounts for testing). Really appreciate you taking the time to reproduce this across clean installs and the newer releases.
That helps clarify that the React peer dependency conflict is upstream and unrelated to the ProseMirror override. Good to see the override resolves the audit findings without introducing additional dependency conflicts.
I’ll compare against our dependency tree and share the output if we’re seeing anything different, particularly around prosemirror-view.
Thanks again for digging into this!