CWE-683Variant

Function Call With Incorrect Order of Arguments

Draft in the CWE catalog · 4 CVEs mapped

4
CVEs mapped
5.9
Median CVSS
What it is

The product calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses.

Recent examples
6.3cvss
CVE-2026-32269

Parse Server OAuth2 adapter app ID validation sends wrong token to introspection endpoint

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.13 and 8.6.39, the OAuth2 authentication adapter does not correctly validate app IDs when appidField and appIds are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request. Deployments using the OAuth2 adapter with appidField and appIds configured are affected. This vulnerability is fixed in 9.6.0-alpha.13 and 8.6.39.

MEDIUMno explanation yet
0%
epss
5.5cvss
CVE-2026-24846

malcontent's archive extraction could write outside extraction directory

malcontent discovers supply-chain compromises through. context, differential analysis, and YARA. Starting in version 1.8.0 and prior to version 1.20.3, malcontent could be made to create symlinks outside the intended extraction directory when scanning a specially crafted tar or deb archive. The `handleSymlink` function received arguments in the wrong order, causing the symlink target to be used as the symlink location. Additionally, symlink targets were not validated to ensure they resolved within the extraction directory. Version 1.20.3 introduces fixes that swap handleSymlink arguments, validate symlink location, and validate symlink targets that resolve within an extraction directory.

MEDIUMno explanation yet
0%
epss
1.8cvss
CVE-2025-47278

Flask uses fallback key instead of current signing key

Flask is a web server gateway interface (WSGI) web application framework. In Flask 3.1.0, the way fallback key configuration was handled resulted in the last fallback key being used for signing, rather than the current signing key. Signing is provided by the `itsdangerous` library. A list of keys can be passed, and it expects the last (top) key in the list to be the most recent key, and uses that for signing. Flask was incorrectly constructing that list in reverse, passing the signing key first. Sites that have opted-in to use key rotation by setting `SECRET_KEY_FALLBACKS` care likely to unexpectedly be signing their sessions with stale keys, and their transition to fresher keys will be impeded. Sessions are still signed, so this would not cause any sort of data integrity loss. Version 3.1.1 contains a patch for the issue.

LOWno explanation yet
0%
epss
The record
Technical detail
CWE ID
CWE-683
Abstraction
Variant
Structure
Simple
Status
Draft