Skip to content

GHSA-h6x7-r5rg-x5fw CVE-2024-29887

Serverpod client accepts any certificate

High Pub
Severity
7.4 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.28%
Chance of exploitation in the next 30 days. Higher than 20.96% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-295 Improper Certificate Validation
Fix
1.2.6
Upgrade serverpod_client to this version or later

Description

This bug bypassed the validation of TSL certificates on all none web HTTP clients in the serverpod_client package. Making them susceptible to a man in the middle attack against encrypted traffic between the client device and the server.

An attacker would need to be able to intercept the traffic and highjack the connection to the server for this vulnerability to be used.

Impact

All versions of serverpod_client pre 1.2.6

Patches

Upgrading to version 1.2.6 resolves this issue.

Affected versions

Pub

PackageVulnerableFixed in
serverpod_client
< 1.2.6
1.2.6

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.

serverpod_client Pub → 1.2.6

dart
dart pub add serverpod_client:^1.2.6

Severity breakdown

CVSS 3.1 7.4

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

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Weakness

CWE-295: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How to prevent it
  • Architecture and Design, Implementation: Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • Implementation: If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-4487-j8r4-4g2f
Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store
Low Same weakness, CWE-295
GHSA-5x38-2vff-x55p
Forge: X.509 basicConstraints bypass in verifyCertificateChain() via deprecated extension OIDs 2.5.29.10 and 2.5.29.13
High Same weakness, CWE-295
EEF-CVE-2026-115693
Custom cacerts or cacertfile do not restrict trust to the pinned CA in hackney
Not rated yet Same weakness, CWE-295
GHSA-6q48-6c7w-9gw2
certifi bundles emSign root CAs with compromised intermediate CA keys
Critical Same weakness, CWE-295
GHSA-2m5v-pch6-74hx
undici vulnerable to TLS certificate validation bypass via dropped tls options in Agent
Critical Same weakness, CWE-295
GHSA-vrv5-2jg9-4mmr
Microsoft Security Advisory CVE-2026-96222 - .NET Spoofing Vulnerability
High Same weakness, CWE-295
GHSA-fqpq-cx42-9jmm
Microsoft Security Advisory CVE-2026-70194 - .NET and Visual Studio Security Feature Bypass Vulnerability
Medium Same weakness, CWE-295
EEF-CVE-2026-103502
hex_core's default HTTP adapter doesn't verify TLS certificates on OTP 24 and 25
Not rated yet Same weakness, CWE-295
Is this in your code?

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