GHSA-9wmc-988h-2mv2 CVE-2024-50703
TeamPass privileges issue
High
Packagist
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.47%
- Chance of exploitation in the next 30 days. Higher than 40.45% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-472 External Control of Assumed-Immutable Web Parameter
- CWE-639 Authorization Bypass Through User-Controlled Key
- Fix
3.1.3.1- Upgrade nilsteampassnet/teampass to this version or later
Description
TeamPass before 3.1.3.1 does not properly prevent a user from acting with the privileges of a different user_id.
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| nilsteampassnet/teampass | < 3.1.3.1 |
3.1.3.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
nilsteampassnet/teampass Packagist → 3.1.3.1
- composer
composer require nilsteampassnet/teampass:^3.1.3.1
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 5.4
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- Low
- Availability
- None
Weakness
CWE-472: External Control of Assumed-Immutable Web Parameter
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CWE-639: Authorization Bypass Through User-Controlled Key
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
How to prevent it
- Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
- Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7rm3-4w6j-8xx4 TeamPass mail_me operation authorization issue | Medium | Also affects nilsteampassnet/teampass |
| GHSA-2697-96mv-3gfm TeamPass does not properly check whether a folder is in a user's allowed folders list | Medium | Also affects nilsteampassnet/teampass |
| GHSA-524r-w8fx-hqg3 TeamPass Cross-site Scripting vulnerability | Medium | Also affects nilsteampassnet/teampass |
| GHSA-2rhg-hqq9-8xjh TeamPass information exposure vulnerability | High | Also affects nilsteampassnet/teampass |
| GHSA-2cv5-qvq3-6276 TeamPass vulnerable to Improper Encoding or Escaping of Output | Medium | Also affects nilsteampassnet/teampass |
| GHSA-97hm-2mfr-2p97 TeamPass Code Injection vulnerability | High | Also affects nilsteampassnet/teampass |
| GHSA-pwrw-g29q-3mp8 TeamPass Cross-site Scripting vulnerability | Medium | Also affects nilsteampassnet/teampass |
| GHSA-qmw8-x364-xxxm Teampass Cross-site Scripting vulnerability | Medium | Also affects nilsteampassnet/teampass |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor