dbcve.org
Integer OverflowWeakness · CWE-190

CVE-2025-55067

HIGH · 7.1 CVSS v3.1 Published 2025-10-23
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
77/100
Remediation priority · High
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
The TLS4B ATG system is vulnerable to improper handling of Unix time values that exceed the 2038 epoch rollover. When the system clock reaches January 19, 2038, it resets to December 13, 1901, causing authentication failures and disrupting core system functionalities such as login access, history visibility, and leak detection termination. This vulnerability could allow an attacker to manipulate the system time to trigger a denial of service (DoS) condition, leading to administrative lockout, operational timer failures, and corrupted log entries.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

The TLS4B ATG system uses a 32-bit signed integer to store Unix timestamps. When the system clock approaches January 19, 2038 (2^31-1 seconds since epoch), the value wraps to December 13, 1901 (negative values), causing authentication token expiration calculations, session validity checks, and operational timers to fail catastrophically. This corrupts authentication state, breaks audit logging, and causes leak detection workflows to terminate prematurely.

MitigationMigrate time handling from 32-bit time_t to 64-bit time_t across all system components, ensuring all timestamp comparisons, storage, and calculations use 64-bit integers. Validate that all third-party libraries and persisted log formats support dates beyond 2038.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify TLS4B ATG system installation
    Locate the TLS4B ATG system binaries or scripts in the environment. Check common installation directories or use 'find / -name '*tls4b*' -o -name '*ATG*' 2>/dev/null' to locate installed components.
    Affected if TLS4B ATG system is not found in the environment, this CVE does not apply.
  2. Determine time_t architecture
    Examine the TLS4B ATG binaries or libraries for the time_t type width. Use 'file <path_to_binary>' to check if binaries are 32-bit or 64-bit. If 32-bit, the time_t is likely 32-bit. Check source code for 'time_t' type definitions or usage of 'int' for timestamp variables.
    Affected if The TLS4B ATG system is compiled as a 32-bit application or uses 32-bit signed integers for timestamp storage.
  3. Check current system date
    Run 'date' command to verify the current system clock. The flaw manifests when the system date approaches or exceeds January 19, 2038 (2^31-1 = 2147483647 seconds since Unix epoch).
    Affected if The system date is at or after January 19, 2038, or approaches this date such that timestamp calculations may wrap to negative values.
  4. Inspect timestamp-related logs for errors
    Review TLS4B ATG system logs for authentication failures, session validation errors, or timer-related crashes. Look for timestamps showing dates in 1901 or negative values. Check 'tail -f /var/log/tls4b/*.log' or equivalent log location.
    Affected if Logs show authentication tokens with expiration dates in 1901, session failures with negative duration values, or timestamp values wrapping to pre-1970 dates.
  5. Verify timestamp field types in configuration
    Examine TLS4B ATG configuration files or database schemas for timestamp fields. Look for 32-bit integer types (int32, long) used to store Unix timestamps rather than 64-bit types (int64, long long).
    Affected if Configuration or database schemas define timestamp fields as 32-bit signed integers.

The environment is affected if the TLS4B ATG system uses 32-bit time_t for timestamp storage and the current or future system date approaches January 19, 2038, causing timestamp wraparound to negative values.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Migrate time handling from 32-bit time_t to 64-bit time_t across all system components, ensuring all timestamp comparisons, storage, and calculations use 64-bit integers. Validate that all third-party libraries and persisted log formats support dates beyond 2038.

Have this fixed Scoped from the published advisory
  • Consultation8.0 h
  • Implementation40.0 h
  • Testing24.0 h
  • Review / QA12.0 h
84.0 hours of engineering $14,560
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $23,296.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-55067 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-55067 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data