What is the CVSS score of CVE-2026-46622?

CVE-2026-46622 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of SolidInvoice are affected by CVE-2026-46622?

SolidInvoice versions prior to 2.3.17 store API authentication tokens in plaintext within the application database, creating a high-risk path to account compromise if database access is breached.. A patch is available.

How to fix or mitigate CVE-2026-46622?

Within 24 hours: Inventory all SolidInvoice deployments and verify versions; assess database access controls and network segmentation. Within 7 days: Upgrade all affected instances to version 2.3.17 (commit 8645391) and rotate all API tokens after upgrade completes. Within 30 days: Confirm patching completion across the entire environment; audit database access logs for unauthorized activity; validate that token hashing is active in production.

SolidInvoice CVE-2026-46622

EUVD-2026-36301 HIGH

Cleartext Storage of Sensitive Information (CWE-312)

2026-06-11 GitHub_M

SQLi Solidinvoice

8.1

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.1 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

6.5 MEDIUM

Exploitation presupposes attacker-controlled database read access (modeled as PR:H), after which token reuse over the network is trivial (AV:N/AC:L) with full read/write API impact and no availability effect.

3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Jun 11, 2026 - 21:02 EUVD

Source Code Evidence Fetched

Jun 11, 2026 - 20:22 vuln.today

Analysis Generated

Jun 11, 2026 - 20:22 vuln.today

DescriptionCVE.org

SolidInvoice is an open-source invoicing platform. Prior to version 2.3.17, API tokens used to authenticate all REST API requests are stored as plaintext strings in the api_tokens database table. Any attacker who obtains read access to the database - through SQL injection, a leaked backup, a misconfigured replica, or insider access - immediately obtains all API credentials for every user with no further effort. This issue has been patched in version 2.3.17.

AnalysisAI

Plaintext credential exposure in SolidInvoice open-source invoicing platform prior to 2.3.17 allows any actor with read access to the application database to harvest every user's REST API token directly from the api_tokens table. Because tokens are stored unhashed, secondary exposures such as SQL injection, stolen backups, replicated databases, or insider access become full account-takeover paths against the API. No public exploit is identified at time of analysis and the issue is not listed in CISA KEV, but the patch in 2.3.17 (commit 8645391) introduces HMAC-SHA256 token hashing keyed by SOLIDINVOICE_APP_SECRET.

Technical ContextAI

SolidInvoice is a Symfony/PHP-based invoicing application (CPE cpe:2.3:a:solidinvoice:solidinvoice). The flaw is a classic CWE-312 (Cleartext Storage of Sensitive Information): the ApiToken Doctrine entity persisted the raw token string returned by ApiTokenManager::generateToken() directly into the api_tokens table, and ApiTokenAuthenticator looked tokens up by exact-match on that plaintext column. The 2.3.17 fix introduces a dedicated ApiTokenHasher service that HMAC-SHA256-hashes tokens before persistence, a GeneratedApiToken DTO that surfaces the plaintext exactly once at creation, an ApiTokenRepository::findOneByPlaintext() method that hashes on lookup, and a Version20317 Doctrine migration that re-hashes existing rows so previously issued tokens keep working.

RemediationAI

Vendor-released patch: upgrade SolidInvoice to 2.3.17 or later (https://github.com/SolidInvoice/SolidInvoice/releases/tag/2.3.17), which ships the Version20317 migration that re-hashes existing rows in place so issued tokens keep working. After upgrading, operators should rotate SOLIDINVOICE_APP_SECRET to invalidate all existing API tokens and require users to regenerate them - note the side effect that this forces every API client to re-enroll. If immediate upgrade is not possible, compensating controls include restricting database connectivity so that only the application host can reach it (blocks leaked-credential reuse but does not help against SQLi), enforcing encrypted-at-rest backups with strict ACLs, auditing for unauthorized replicas, and proactively revoking and reissuing all API tokens via the management UI while monitoring api_tokens for unexpected reads. See advisory GHSA-qjfc-h39r-cgwq for full guidance.