fix: force ejs to ^6.0.1 via npm overrides - #314
Merged
shrutiburman merged 16 commits intoSep 4, 2026
Merged
shrutiburman merged 16 commits into
shrutiburman merged 16 commits into
Conversation
- Drop Node 20 from all CI test matrices; minimum is now Node 22 - Update hardcoded node-version '20' → '22' in release jobs - Switch test job runners to ubuntu-x64 - SHA-pin actions/checkout (v4) and actions/setup-node (v6) - Add Artifactory OIDC Auth step to all test jobs - Add ARTIFACTORY_URL env var and id-token: write permissions - Add lockfile-hygiene job (twilio/sdk-actions/npm-lockfile-hygiene) to cli-core-test.yml - Guard test jobs with if: github.repository_owner == 'twilio' - Fix dead SonarCloud condition (16.x → lts/*) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The npm-lockfile-hygiene gate failed: all 878 resolved URLs in package-lock.json pointed at npmjs.artifacts.twilio.com, which an external consumer cannot reach. The action allows only registry.npmjs.org, registry.yarnpkg.com, github.com and codeload.github.com. - rewrote all 878 resolved URLs to registry.npmjs.org. Package set is unchanged: 1136 entries, identical versions and integrity hashes, so the same tarballs still verify - `make install` no longer does `rm -f package-lock.json`. Deleting it forced a full re-resolution on every run, which is why CI began failing without any code change: GitHub moved the runners to Node 24 (Node 20 deprecation), changing the bundled npm and therefore the resolved tree. It also regenerated the lockfile through whatever registry the developer had configured, which is how the Artifactory URLs got committed - `npm install --no-optional` -> `npm ci --omit=optional`. --no-optional is a deprecated alias npm warns about on every run, and npm ci installs the committed tree instead of re-resolving. Verified package.json and the lockfile are in sync (lockfileVersion 3), so npm ci will not fail on drift This does not unblock CI on its own. Two packages in the tree are still refused by jfrog curation: npm@7.24.2 via @semantic-release/npm (^7.0.0), CVE-2021-43616 CVSS 9.8. Fix exists at >= 8.4.1, but ^7.0.0 cannot reach it, and @semantic-release/npm@7.1.3 is transitive, so it needs a semantic-release upgrade ejs@3.1.10 via @oclif/core@1.26.2 and a nested copy under @oclif/plugin-help. CVE-2023-29827 CVSS 9.8, and curation reports no version resolves it, so it needs either an exception or dropping @oclif/core v1
Adds an informational step that tries `npm pack` for ejs 3.1.10 and 6.0.1 through the registry CI is authenticated against, and reports allowed/blocked in the job summary. 3.1.10 is what @oclif/core <= 4.13.3 pulls; 6.0.1 is what >= 4.13.4 pulls, so this answers whether upgrading past that boundary clears the block -- without committing to the upgrade first. It has to run in CI. A local probe cannot answer it: developer npm points at npmjs.artifacts.twilio.com/virtual-npm-twilio, which allows ejs 3.1.10, while the 403 in CI came from twilio.jfrog.io/virtual-npm-thirdparty. Different Artifactory repositories carry different curation policies, and local credentials get E401 against the CI one, so only a CI run is authoritative. continue-on-error, since it is a question rather than a gate. Also trims the trailing internal catalog URL out of the failure reporting added earlier, for both the curation notice and the 403 line -- the tarball filename is enough to identify the package.
Removes the failure-only step that grepped the install log for curation blocks, and restores `- run: make install` to its original form -- the tee to /tmp/install.log and the step id existed only to feed it. The curation probe still reports which ejs versions are allowed, which is the question that actually needed answering.
JFrog Curation blocks ejs 3.x tree-wide (CVE-2023-29827, CVSS 9.8, no fixed version on the 3.x line), which breaks installs since @oclif/core and the nested @oclif/core pulled in by @oclif/plugin-help both depend on ejs@^3.x. An override forces every consumer in the tree to a single ejs@6.0.1 without needing to bump any oclif package itself.
…itical-cve-override # Conflicts: # package-lock.json
Collaborator
Author
|
Note: this branch merges in the (still-open) #312 CI/publishing changes so this PR runs against the real Artifactory/Curation-gated pipeline (the same pipeline whose CI log first surfaced the ejs 3.x Curation block this fix addresses). Once #312 merges to |
shrutiburman
changed the base branch from
main
to
fix/ejs-critical-cve-override_internal
September 4, 2026 07:33
shrutiburman
merged commit Sep 4, 2026
824d267
into
twilio:fix/ejs-critical-cve-override_internal
7 of 10 checks passed
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ejs3.x line (CVE-2023-29827, CVSS 9.8 — "no fixed version" on 3.x), which breaks installs since@oclif/core@^1.16.0and the nested@oclif/core@2.16.0pulled in by@oclif/plugin-help@^5.1.3both depend onejs@^3.x."overrides": {"ejs": "^6.0.1"}topackage.jsonto force every consumer in the dependency tree onto a single patchedejs@6.0.1, without bumping any@oclif/*package.ejs.render()(the only API these packages call) behaves identically under 6.x.Test plan
npm explain ejsshows a singleejs@6.0.1resolved everywhere (was two nested copies ofejs@3.x)npm run lintpassesnpm test— 205/205 passing