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

GHSA-fm76-w8jw-xf8m

HIGH

@saltcorn/plugins-loader unsanitized plugin name leads to a remote code execution (RCE) vulnerability when creating plugins using git source

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

Blast Radius

1 pkg affected
📦@saltcorn/plugins-loader

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

When creating a new plugin using the git source, the user-controlled value req.body.name is used to build the plugin directory where the location will be cloned. The API used to execute the git clone command with the user-controlled data is child_process.execSync. Since the user-controlled data is not validated, a user with admin permission can add escaping characters and execute arbitrary commands, leading to a command injection vulnerability.

Details

Relevant code from source (req.body) to sink (child_process.execSync).

router.post(
  "/",
  isAdmin,
  error_catcher(async (req, res) => {
    const plugin = new Plugin(req.body); // [1] 
      [...]
      try {
        await load_plugins.loadAndSaveNewPlugin( // [3] 
          plugin,
          schema === db.connectObj.default_schema || plugin.source === "github"
        );
        [...]
    }
  })
);

class Plugin {
  [...]
  constructor(o: PluginCfg | PluginPack | Plugin) {
    [...]
    this.name = o.name; // [2] 
    [...]
}

const loadAndSaveNewPlugin = async (plugin, force, noSignalOrDB) => {
  [...]
  const loader = new PluginInstaller(plugin); // [4] 
  const res = await loader.install(force); // [7] 
  [...]
};

class PluginInstaller {
  constructor(plugin, opts = {}) {
    [...]
    const tokens =
      plugin.source === "npm"
        ? plugin.location.split("/")
        : plugin.name.split("/"); // [5] 
    [...]
    this.tempDir = join(this.tempRootFolder, "temp_install", ...tokens); // [6] 
    [...]
  }

  
  async install(force) {
    [...]
    if (await this.prepPluginsFolder(force, pckJSON)) { // [8] 
    [...]
  }

  async prepPluginsFolder(force, pckJSON) {
    [...]
    switch (this.plugin.source) {
      [...]
      case "git":
        if (force || !(await pathExists(this.pluginDir))) { 
          await gitPullOrClone(this.plugin, this.tempDir); // [9] 
	  [...]
  }

const gitPullOrClone = async (plugin, pluginDir) => {
  [...]
  if (fs.existsSync(pluginDir)) {
    execSync(`git ${setKey} -C ${pluginDir} pull`);
  } else {
    execSync(`git ${setKey} clone ${plugin.location} ${pluginDir}`); // [10] 
  }
  [...]
};

PoC

  • check that the file will be created by the command echo "hello">/tmp/HACKED does not exists:
cat /tmp/HACKED
cat: /tmp/HACKED: No such file or directory
  • login with an admin account
  • visit http://localhost:3000/plugins/new
  • enter the following fields:
    • Name: ;echo "hello">/tmp/HACKED
    • Source: git
    • other fields blank
  • click Create
  • you will get an error saying ENOENT: no such file or directory, .... but the command touch /tmp/HACKED will be executed
  • to verify:
cat /tmp/HACKED
hello

Impact

Remote code execution

Recommended Mitigation

Sanitize the pluginDir value before passing to execSync. Alternatively, use child_process. execFileSync API (docs: https://nodejs.org/api/child_process.html#child_processexecfilesyncfile-args-options)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@saltcorn/plugins-loaderall versions1.0.0-beta.14

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/plugins-loader. 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/plugins-loader to 1.0.0-beta.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fm76-w8jw-xf8m 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-fm76-w8jw-xf8m 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-fm76-w8jw-xf8m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary When creating a new plugin using the `git` source, the user-controlled value `req.body.name` is used to build the plugin directory where the location will be cloned. The API used to execute the `git clone` command with the user-controlled data is `child_process.execSync`. Since the user-controlled data is not validated, a user with admin permission can add escaping characters and execute arbitrary commands, leading to a command injection vulnerability. ### Details Relevant code from source (`req.body`) to sink (`child_process.execSync`). - file: https://github.com/saltcorn/salt
O3 Security · Impact-Aware SCA

Is GHSA-fm76-w8jw-xf8m in your dependencies?

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

Scan my dependencies How O3 SCA works