GHSA-pf56-h9qf-rxq4 is a medium-severity (CVSS 6.1) vulnerability in @saltcorn/server. A fix is available for @saltcorn/server — see the affected versions and patch details below.
Saltcorn Server Stored Cross-Site Scripting (XSS) in event logs page
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@saltcorn/servernpmDescription
Summary
Event log data is not properly sanitized leading to stored Cross-Site Scripting (XSS) vulnerability.
Details
- file: https://github.com/saltcorn/saltcorn/blob/v1.0.0-beta.13/packages/server/routes/eventlog.js#L445
router.get(
"/:id",
isAdmin,
error_catcher(async (req, res) => {
const { id } = req.params;
const ev = await EventLog.findOneWithUser(id);
send_events_page({
[...]
contents: {
type: "card",
contents:
[...]
) +
div(
{ class: "eventpayload" },
ev.payload ? pre(JSON.stringify(ev.payload, null, 2)) : "" //<---
),
},
});
})
PoC
The following PoC demonstrates how a non-admin user with permission to read/write on a table can inject malicious javascript code that will be executed in the event log admin panel if event logs are enabled.
To demonstrate this issue, we need to prepare some components. The following steps should be executed with an admin user.
- create a table with one column of type string set read/write permission to staff users (just as an example)
- visit
http://localhost:3000/table/new - create a table with
Table namemy_table_xssand clickCreate - click
Add fieldto add a field withLabelcalledpayloadof typeStringand clickNext >> - leave default values for
Attributesand clickNext >>- it should redirect tohttp://localhost:3000/table/<table-number> - under
Edit table properties, setMinimum role to readandMinimum role to writetostaff
- create an edit view so that staff users can insert more data
- visit
http://localhost:3000/vieweditanc clickCreate View - set the following values:
View name:my_xss_viewView pattern:EditTable:my_table_xssMinimum role:staff
- click
Configure >> - on page
http://localhost:3000/viewedit/config/my_xss_viewclickNext >>and thenFinish >> - you should see a message
View my_xss_view saved
- edit the site structure to add the View just created so that
staffusers can access it
- visit
http://localhost:3000/menu - set the following values:
Type:ViewView:my_xss_view [Edit]Text label:viewMinimum role:staff
- click
Add
- create an event that will log when data is inserted in the
my_table_xsstable create at step 1
- visit
http://localhost:3000/eventlog/settings - under
Which events should be logged?select:[X] Insert[X] Insert my_table_xss
Login with a user with staff role (you can do the same steps also with an admin user)
- visit
http://localhost:3000/view/my_xss_view - in the
payloadfield insert"<svg/onload=alert(`xss`)>and clickSave
With an admin user inspect the log entry generated by the above action:
- visit
http://localhost:3000/eventlog - click on the event log generated (
http://localhost:3000/eventlog/<event-number>) - an alert will appear
Impact
Stored Cross-Site Scripting (XSS)
Recommended Mitigation
Sanitize the user input before building HTML elements
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @saltcorn/server | all versions | 1.0.0-beta.16npm install @saltcorn/server@1.0.0-beta.16 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @saltcorn/server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @saltcorn/server to 1.0.0-beta.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pf56-h9qf-rxq4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-pf56-h9qf-rxq4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-pf56-h9qf-rxq4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pf56-h9qf-rxq4 in your dependencies?
O3 Security finds GHSA-pf56-h9qf-rxq4 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.