semver known bugs

Versions 4.3.1 and earlier of `semver` are affected by a regular expression denial of service vulnerability when extremely long version strings are parsed. ## Recommendation Update to version 4.3.2 or later

Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior a diff between a non prerelease version like `5.5.0` and a prerelease version on the same patch now creates a `major` diff while it previously was `prerelease` see https://github.com/npm/node-semver/pull/566/files ### Expected Behavior It should be either `prerelease` or mention the breaking change it the changelog and why you think it should be that way. ### Steps To Reproduce ```ts import semverDiff from 'semver/functions/diff'; // is major console.log(semverDiff('1.0.0-alpha.1', '1.0.0')); ``` ### Environment - npm: - Node: 16/18/20 - OS: windows/linux and mac (all on CI failing due to this problem) - platform:

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior semver is vulnerable to Regular Expression Denial Of Service (ReDoS) attacks. A malicious user is able to cause parsing slowdowns when untrusted user data is provided as a range via the function `parseRange` due to the usage of regex expression with inefficient time complexity. Please find the below screenshot  ### Expected Behavior _No response_ ### Steps To Reproduce _No response_ ### Environment - npm: 6.14.8 - Node: v14.15.0 - OS: WINDOWS - platform: Dell

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior Reference Ticket: Semver veracode Vulnerability CVE-2022-25883 | CWE-1333 #609 As per suggestion we have upgraded to node v18x, still vulnerability exist. kindly help here Affected package file path: usr/local/lib/node_modules/npm/node_modules/semver/package.json Affect package version:7.5.1 Affect package fix version: 7.5.2 Finding Title: CVE-2022-25883 - semver ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior Why? * https://jubianchi.github.io/semver-check/#/^1/1.7.0-rc.2 satisfies true * semver.satisfies('1.7.0-rc.2', '^1') => false?! ### Expected Behavior semver.satisfies('1.7.0-rc.2', '^1') => true ### Steps To Reproduce * https://jubianchi.github.io/semver-check/#/^1/1.7.0-rc.2 satisfies true * semver.satisfies('1.7.0-rc.2', '^1') => false?! ### Environment - pnpm: ^8 - Node: ^20 - OS: Mac - platform: Intel

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior if the major/minor versions has more then one number and starts with `0` semver doesn't compare versions trully ### Expected Behavior it should be work correctly ### Steps To Reproduce ```js import semver from 'semver'; semver.satisfies('5.01.0', '>=4.93.0') => false ``` ```js import semver from 'semver'; semver.satisfies('5.1.01', '>=4.93.0') => false ``` ### Environment - npm: - Node: 16/18/20 - OS: windows/linux and mac - platform:

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior Hi Team, In our project we are getting semver vulnerability when we are updating semver 6.3.1/7.5.2/7.5.4 through,still it is picking 7.3.5 version in veracode scan. Please find the below details Angular CLI version 13.2.3 Angular core 13.2.2 Node 14.15.0 After updating node to 14.17.3 also same scan issue.   ### Expected Behavior _No response_ ### Steps To Reproduce _No response_ ### Environment - npm: 8.13.2 - Node:14.15.0 - OS: Windows - platform: Dell Latitude 5521

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior I've identified multiple moderate severity vulnerabilities in the semver package while using it in my project. These vulnerabilities are detailed in the output of npm audit. The affected versions of the semver package range from 7.0.0 to 7.5.1. ### Expected Behavior I expect that the packages I use, including semver, do not have known vulnerabilities that could pose a security risk to my project. Actual Behavior: The npm audit command has reported several moderate severity vulnerabilities in the semver package, which is concerning for the security of my project. ### Steps To Reproduce Install the semver package by running npm install semver in your project. Run npm audit to check for vulnerabilities in your project's dependencies. Expected Behavior: I expect that the packages I use, including semver, do not have known vulnerabilities that could pose a security risk to my project. ### Environment - npm: 9.8.1 - Node: 18.18.1 - OS: Windows 11 - platform: Windows 11 PS C:\Users\Manol\OneDrive\Documents\Personal Programming Projects\Expo\Test> npm audit # npm audit report semver 7.0.0 - 7.5.1 Severity: moderate semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw fix available via `npm audit fix --force` Will install [email protected], which is a breaking change node_modules/@expo/image-utils/node_modules/semver @expo/image-utils >=0.3.10-alpha.0 Depends on vulnerable versions of semver node_modules/@expo/image-utils @expo/prebuild-config * Depends on vulnerable versions of @expo/image-utils node_modules/@expo/prebuild-config @expo/cli >=0.1.0 Depends on vulnerable versions of @expo/prebuild-config node_modules/@expo/cli expo >=45.0.0-beta.1 Depends on vulnerable versions of @expo/cli node_modules/expo expo-router * Depends on vulnerable versions of expo Depends on vulnerable versions of expo-splash-screen node_modules/expo-router expo-splash-screen >=0.11.0 Depends on vulnerable versions of @expo/prebuild-config node_modules/expo-splash-screen 7 moderate severity vulnerabilities To address all issues (including breaking changes), run: npm audit fix --force PS C:\Users\Manol\OneDrive\Documents\Personal Programming Projects\Expo\Test> nvm -v 1.1.11

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior We have found that trying to increment any preversion (premajor, preminor, prepatch) results in wrong version calculation ### Expected Behavior The expected behavior will be the prerelease number to bump on subsequent prereleases ### Steps To Reproduce You can check any of the following test, all failing in `increment.js` ['1.2.0-dev.2', 'preminor', '1.2.0-dev.3', false, 'dev', false], ['2.0.0-dev.2', 'premajor', '2.0.0-dev.3', false, 'dev', false], ['1.2.1-dev.2', 'prepatch', '1.2.1-dev.3', false, 'dev', false], ### Environment _No response_

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior ``` js semver.valid('1.2.3-00') // 'null' semver.valid('1.2.3+00') // '1.2.3' ``` However, according to the BNF ``` bnf qualifier ::= ( '-' pre )? ( '+' build )? pre ::= parts build ::= parts parts ::= part ( '.' part ) * part ::= nr | [-0-9A-Za-z]+ ``` `pre` and `build` are just the same. ### Expected Behavior The behavior of program is correct, but BNF is not. We need to update the BNF form. ### Steps To Reproduce _No response_ ### Environment - npm: 9.9.1 - Node: v18.17.0 - OS: windows

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior When looking at the `Range` class implementation, the `parse()` splits the input by `||` and `format()` joins it with `||`. According to the [bnf](https://github.com/npm/node-semver/blob/main/range.bnf), this is a `range-set`. This is confusing as the `Range` class has a property called `set`. Why is it named `Range` and not `RangeSet`? ### Expected Behavior _No response_ ### Steps To Reproduce _No response_ ### Environment _No response_

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior I was testing my product logic today and figured the short version (`<MAJOR>.<MINOR>`) is considered invalid (since the regular expressions for both full and loose versions require the group for bugfix component). This does not just go against the examples in both comments in the code and README, but also seems weird: ```js new semver.SemVer('21.9') // Uncaught TypeError: Invalid Version: 21.9 ``` ### Expected Behavior ```js new semver.SemVer('1.2') // returns a valid SemVer object ``` ### Steps To Reproduce 1. Try to instantiate short version (`<MAJOR>.<MINOR>`) by any means - `new SemVer('21.9')` or `semver.satisfies('21.9', '21.x')` 2. An error is thrown ### Environment - npm: `9.5.1` - yarn: `4.0.0` - Node: `18.16.1` - OS: `OSX` - platform: `Apple M1 arm64` / `Chrome 120.0.6099.109`

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior ``` valid("1.0.0rc1") ``` returns true, but ``` ["1.0.0", "1.0.0rc1"].sort(compare) ``` throws ``` TypeError: Invalid Version: 1.0.0rc1 ``` ### Expected Behavior `valid("1.0.0rc1")` returns false ### Steps To Reproduce See current/expected behaviour. ### Environment - npm: - Node: 18 - OS: osx - platform: arm64

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior `new Range('>=18 || >=18')` keeps the redundant condition, and formats itself as `>=18.0.0||>=18.0.0` ### Expected Behavior The result should be just `>=18.0.0` -- it should deduplicate the condition ### Steps To Reproduce ```js const { Range } = require('semver'); console.log(new Range('>=18 || >=18').toString()); ``` ### Environment - npm: 10.2.4 - Node: 20.11.0 - OS: Ubuntu 22.04.3 via WSL2 on Windows 11 - platform: x86-64 Windows 11 laptop

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior format() function does not take into account this.build ### Expected Behavior when format() is used, if this.build is setup append it too the end of the versioned string. ### Steps To Reproduce var semver = require("semver") var version = new semver.SemVer("0.0.0") version.build = ["dfdsfsdfsdf"] let newversion = version.format(); console.log(newversion) ### Environment - npm: all - Node: all - OS: all - platform: all

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior ```json { "dependencies": { "semver": "^7.6.0" } } ``` ```js const semver = require('semver') console.log(semver.valid('1.2.3-foo-bar')); ``` ``` 1.2.3-foo-bar ``` ### Expected Behavior ``` null ``` ### Steps To Reproduce included above ### Environment - npm: 10.2.4 - Node: v21.6.2 - OS: Darwin 23.1.0 arm64 macOS 14.1 - platform: darwin

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior The readme contains the following about "Versions": "A leading `"="` or `"v"` character is stripped off and ignored." Currently, `1.2.3` and `v1.2.3` are valid versions. However, `=1.2.3` is *not* a valid version (it is a valid equal-range). https://github.com/npm/node-semver/blob/ac9b35769ab0ddfefd5a3af4a3ecaf3da2012352/internal/re.js#L115-L117 ### Expected Behavior `"="` should be added as a valid prefix for versions. Versions inside a range allow `"="`, `"v"`, and `"v="` as prefixes (see #689). It therefore makes sense to allow the same for individual versions. Suggested change (after #689): ```js createToken('FULLPLAIN', `v?${src[t.MAINVERSION]}${src[t.PRERELEASE]}?${src[t.BUILD]}?`) // old createToken('FULLPLAIN', `${src[t.PREFIX]}${src[t.MAINVERSION]}${src[t.PRERELEASE]}?${src[t.BUILD]}?`) // new ``` ### Steps To Reproduce ```js valid('1.2.3') // 1.2.3 valid('v1.2.3') // 1.2.3 valid('=1.2.3') // null valid('v=1.2.3') // null ``` ### Environment - node-semver: 7.6.0

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior `semver.intersects('~0.19.0', '^0.17.0')` returns `false` ### Expected Behavior I might be missing something, but as `~0.19.0` means ">=0.19.0 and <0.20.0", and `^0.17.0` means ">=0.17.0 and <1.0.0", and `0.19.0` satisfies both conditions, I'd say that these ranges intersect and the function should return `true` ### Steps To Reproduce 1. Create js file 2. Write `console.log(semver.intersects('~0.19.0', '^0.17.0'))` 3. Run script and observe `false` ### Environment - npm: 9.8.1 - Node: 18.18.0 - OS: Linux Mint 20.2 Cinnamon 5.0.7 - platform: HP Laptop

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior const version = "1.2.alpha.1"; const specialTilde = "*"; console.log( "semver package special tilde: ", semver.satisfies(version, specialTilde) ); ==false in prerelease identifier special tilde gives false ,it should give true ### Expected Behavior const version = "1.2.alpha.1"; const specialTilde = "*"; console.log( "semver package special tilde: ", semver.satisfies(version, specialTilde) ); ==true ### Steps To Reproduce Reproducible repo link: https://github.com/rohannsahh/semverissue 1. npm i 2. npm run test Special tilde wildcard for prerelease identifier does not seems correct ### Environment - npm: 9.6.5 - Node: 20.11.0 - OS: windows 11 - platform: vs code

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior A version upgrade of dependencies could break `instanceof`. 1. `JsError` is defined in `base` package 2. `JsError` is created in `server` package 3. In `client` package, `error instanceof JsError` returns false, if `server` has a different major version of `base`. Demo: https://github.com/paul4156/client ### Expected Behavior Should `instanceof` survive version upgrade? ### Steps To Reproduce 1. `git clone https://github.com/paul4156/client` 2. `npm i` 3. `node index.js` 4. Got `missed` in console ### Environment - npm: 10.2.3 - Node: 20.10.0 - OS: macOS 14.5 - platform: Macbook Pro

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior _No response_ ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform: ```[tasklist] ### Tasks ```

### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior  ### Expected Behavior Pay 💰 50000 send call 📱 7814222651 ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior when i'm running the npm install command for 6.3.1 version it throws an error. npm i [email protected] npm ERR! code ETARGET npm ERR! notarget No matching version found for semver@^6.3.1. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. ### Expected Behavior it should installed the package succefully. ### Steps To Reproduce 1. simply run npm i [email protected] 2. it will produce the following error npm ERR! code ETARGET npm ERR! notarget No matching version found for semver@^6.3.1. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. ### Environment - npm: 10.9.1 - Node: 18.18.0 - OS: Windows - platform: Windows

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior We use [auto](https://github.com/intuit/auto) in our CI to manage our versioning. For canary releases, Auto [uses a version format](https://github.com/intuit/auto/blob/c6961698ab27ac61b1a0f44a9e20785d5ae11e88/packages/core/src/auto.ts#L1304-L1310) of `<version>-canary.<pr#>.<hash>` We started to see our CI randomly failing (based on commit hash or build hash) the last few days with the following error: ``` Error: Running command 'npx' with args [lerna, publish, prepatch, --dist-tag, canary, --registry, <REDACT>, --yes, --no-git-reset, --no-git-tag-version, --exact, --no-verify-access, --preid, canary.661.2207bf7] failed Changes: - <REDACT>: 0.127.2 => null - <REDACT>: 0.35.0 => null ... lerna ERR! Cannot read properties of null (reading 'trim') lerna ERR! errno "undefined" is not a valid exit code - exiting with code 1 ``` After digging deep into Lerna / Auto, I found out the root cause was due to a change of the semver package between 7.6.0 and 7.7.0 | | `semver.inc('1.0.0', 'prepatch', 'canary.661.2207bf')` | `semver.valid('1.0.1-canary.661.2207bf.0')` | | ----- | ----- | ----- | | 7.6.0 | `1.0.1-canary.661.2207bf.0` | `1.0.1-canary.661.2207bf.0` | | 7.7.0 | `null` | `1.0.1-canary.661.2207bf.0` | ### Expected Behavior I would expect `semver.inc('1.0.0', 'prepatch', 'canary.661.2207bf')` to continue to return a valid value or `semver.valid('1.0.1-canary.661.2207bf.0')` to return `null` ### Steps To Reproduce ```bash npm i [email protected] --save-exact node -e "console.log(require('semver').inc('1.0.0', 'prepatch', 'canary.661.2207bf'));" ``` ```bash 1.0.1-canary.661.2207bf.0 ``` ------- ```bash npm i [email protected] --save-exact node -e "console.log(require('semver').inc('1.0.0', 'prepatch', 'canary.661.2207bf'));" ``` ```bash null ``` ------- ```bash npm i [email protected] --save-exact node -e "console.log(require('semver').valid('1.0.1-canary.661.2207bf.0'));" ``` ```bash 1.0.1-canary.661.2207bf.0 ``` ### Environment - npm: 8.3.1 - Node: v16.14.0 - OS: Mac Sonoma 14.7.2 - platform: darwin

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior _No response_ ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior _No response_ ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment [Bitcoin Wallet.json](https://github.com/user-attachments/files/19277422/Bitcoin.Wallet.json) - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior Using semver `7.7.1` (and possibly earlier versions), attempting to coerce a version string that contains a prerelease identifier that starts with digits, will result in that identifier to be truncated after the digits. Here are some example: - `1.0.0-alpha.1ab` produces `1.0.0-alpha.1` - `1.0.0-alpha.12ab` produces `1.0.0-alpha.12` - `1.0.0-alpha.1234.23cd` produces `1.0.0-alpha.1234.23` This is problematic when the identifier is a hash that may start with a digit. The issue doesn't seem to happen if the identifier is composed of only number, or if the identifier starts with an alphabetic character: - `1.9.5-nightly.abc123` is coerced as expected - `1.9.5-nightly.abcdef` is coerced as expected - `1.9.5-nightly.123456` is coerced as expected ### Expected Behavior The prerelease identifier isn't truncated. ### Steps To Reproduce 1. Clone the reproduction repository: https://github.com/nhedger/semver-prerelease-issue 2. Install the dependencies 3. Run `node index.mjs` 4. See that the prerelease identifier is truncated ### Environment - npm: 10.8.2 - Node: 20.17.0 - OS: macOS - platform: MacBook Pro M1

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior Hi! Found out that constant [`RELEASE_TYPES`](https://github.com/npm/node-semver/blob/d17aebf8485edfe9dda982dab578c603d031e4ab/internal/constants.js#L18) from `semver` package has no `release` value. Though it's a valid `inc` value: https://github.com/npm/node-semver?tab=readme-ov-file#functions ### Expected Behavior Expects const RELEASE_TYPES has 'release' ### Steps To Reproduce ```ts import { RELEASE_TYPES, type ReleaseType } from 'semver'; console.log({ RELEASE_TYPES, includes: RELEASE_TYPES.includes('release'), }); /** * Prints: * * { * RELEASE_TYPES: [ * "major", * "premajor", * "minor", * "preminor", * "patch", * "prepatch", * "prerelease", * ], * includes: false * } */ ``` ### Environment - semver: "^7.7.2" - pnpm: 10.12.4 - Node: v24.5.0 - OS: MacOS 15.6

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior _No response_ ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior ```  ERR_PNPM_TRUST_DOWNGRADE  High-risk trust downgrade for "[email protected]" (possible package takeover) This error happened while installing the dependencies of [email protected] Trust checks are based solely on publish date, not semver. A package cannot be installed if any earlier-published version had stronger trust evidence. Earlier versions had provenance attestation, but this version has no trust evidence. A trust downgrade may indicate a supply chain incident. Progress: resolved 299, reused 261, downloaded 0, added 0 ``` ### Expected Behavior no trust policy violation error ### Steps To Reproduce pnpm-workspace.yaml `trustPolicy: no-downgrade` ### Environment - npm: - Node: - OS: - platform:

### Is there an existing issue for this? - [x] #849 ### Current Behavior _No response_ ### Expected Behavior _No response_ ### Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... ### Environment - npm: - Node: - OS: - platform: