Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-pf56-h9qf-rxq4

MEDIUM

Saltcorn Server Stored Cross-Site Scripting (XSS) in event logs page

Published
Oct 7, 2024
Updated
Oct 7, 2024
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
📦@saltcorn/server

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Event log data is not properly sanitized leading to stored Cross-Site Scripting (XSS) vulnerability.

Details

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.

  1. 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 name my_table_xss and click Create
  • click Add field to add a field with Label called payload of type String and click Next >>
  • leave default values for Attributes and click Next >> - it should redirect to http://localhost:3000/table/<table-number>
  • under Edit table properties, set Minimum role to read and Minimum role to write to staff
  1. create an edit view so that staff users can insert more data
  • visit http://localhost:3000/viewedit anc click Create View
  • set the following values:
    • View name: my_xss_view
    • View pattern: Edit
    • Table: my_table_xss
    • Minimum role: staff
  • click Configure >>
  • on page http://localhost:3000/viewedit/config/my_xss_view click Next >> and then Finish >>
  • you should see a message View my_xss_view saved
  1. edit the site structure to add the View just created so that staff users can access it
  • visit http://localhost:3000/menu
  • set the following values:
    • Type: View
    • View: my_xss_view [Edit]
    • Text label: view
    • Minimum role: staff
  • click Add
  1. create an event that will log when data is inserted in the my_table_xss table 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 payload field insert "<svg/onload=alert(`xss`)> and click Save

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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@saltcorn/serverall versions1.0.0-beta.16

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @saltcorn/server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. 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.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-pf56-h9qf-rxq4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

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

### 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 ```js 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(JS
O3 Security · Impact-Aware SCA

Is GHSA-pf56-h9qf-rxq4 in your dependencies?

O3 detects GHSA-pf56-h9qf-rxq4 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.