CVE-2025-13375

Published Feb 4, 2026

Last updated 6 months ago

CVSS critical 9.8
hsm

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-13375 is a security vulnerability found in specific versions of IBM's Common Cryptographic Architecture (CCA), including versions 7.5.52 and 8.4.82. This flaw, categorized under CWE-250 for improper authorization, enables an unauthenticated attacker to execute arbitrary commands on the affected system with elevated privileges. The vulnerability allows for the bypass of authentication and authorization mechanisms, making it remotely exploitable without requiring any user interaction. The CCA acts as a software interface for IBM Hardware Security Modules (HSMs), which are designed to protect digital keys and sensitive encrypted data. Exploitation of CVE-2025-13375 could impact the confidentiality, integrity, and availability of the cryptographic card and its dependent applications, potentially leading to unauthorized data access, data modification, or disruption of system operations.

Description
IBM Common Cryptographic Architecture (CCA) 7.5.52 and 8.4.82 could allow an unauthenticated user to execute arbitrary commands with elevated privileges on the system.
Source
psirt@us.ibm.com
NVD status
Deferred

Risk scores

CVSS 3.1

Type
Primary
Base score
9.8
Impact score
5.9
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity
CRITICAL

Weaknesses

psirt@us.ibm.com
CWE-250

Social media

Hype score
Not currently trending

  1. IBMのHSM連携基盤「CCA」に深刻な脆弱性（CVE-2025-13375）　早急な更新を推奨 https://t.co/qEaVS1Lkha

    @cybersecnews_jp

    10 Feb 2026

    40 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. CVE-2025-13375: Critical IBM Crypto Flaw (CVSS 9.8) Exposes HSMs https://t.co/bJUt73gAMZ

    @Karma_X_Inc

    7 Feb 2026

    49 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2025-13375: Critical IBM Crypto Flaw (CVSS 9.8) Exposes HSMs https://t.co/JuN1cnyjyI

    @CrowdCyber_Com

    7 Feb 2026

    51 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  4. CVE-2025-13375: Critical IBM Crypto Flaw (CVSS 9.8) Exposes Hardware Security Modules - Time to update those IBM cryptographic coprocessors, folks. #cybersecurity #ibm #vulnerability #cryptography https://t.co/Dy4N53HPRt

    @xplain_it_again

    7 Feb 2026

    62 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    2 Replies

    0 Quotes

  5. IBMはCommon Cryptographic Architecture（CCA）における深刻な脆弱性CVE-2025-13375を公表した。CVSSは9.8と極めて高く、外部から到達可能な場合、未認証の攻撃者が任意のコマンドを管理者権限で実行できる。

    @yousukezan

    6 Feb 2026

    867 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. IBMの暗号コンポーネントCommon Cryptographic Architecture (CCA)に重大(Critical)な脆弱性。CVE-2025-13375はCVSSスコア9.8で、無認証の攻撃者が特権で任意コードを実行可能。HSMも露出する影響。 https://t.co/kj1fBlDqy3

    @__kokumoto

    6 Feb 2026

    780 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. IBM warns of critical flaw CVE-2025-13375 (CVSS 9.8) in CCA software. Unauthenticated attackers can hijack HSMs. Update to v7.5.53/v8.4.84 now. #IBM #CyberSecurity #CVE202513375 #HSM #InfoSec #Cryptography #SysAdmin https://t.co/17lvPBbwvv

    @Daily_CyberSec

    6 Feb 2026

    242 Impressions

    1 Retweet

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. [CVE-2025-13375: CRITICAL] IBM Common Cryptographic Architecture (CCA) 7.5.52 and 8.4.82 could allow an unauthenticated user to execute arbitrary commands with elevated privileges on the system.#cve,CVE-2025-13375,#cybersecurity https://t.co/cIxUmR52WE

    @CveFindCom

    5 Feb 2026

    95 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  9. CVE-2025-13375 IBM Common Cryptographic Architecture (CCA) 7.5.52 and 8.4.82 could allow an unauthenticated user to execute arbitrary commands with elevated privileges on the system. https://t.co/fcHvUCPWqj

    @CVEnew

    4 Feb 2026

    144 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Related CVEs

  1. Temporal Server decided whether a Workflow completion callback was internal by reading a caller-supplied HTTP header. An authenticated caller holding only write permission in a single namespace could attach a completion callback whose URL host matched the configured callback address allowlist, whose URL path was any Temporal HTTP API route, and whose header map contained a non-empty header named source. When the History service delivered that callback, the non-empty source header caused it to re-target the request at the local frontend client and rewrite only the scheme and host, preserving the caller's path, query, and request body. Where an internal frontend is deployed with its HTTP API enabled, that client resolves to the internal frontend, which authorizes every request as a system administrator without requiring authentication information. The result is that the server performs an attacker-chosen state-changing HTTP POST against its own administrative API on the caller's behalf, in namespaces where the caller has no permission. The caller never needs network access to the internal frontend, because the History service makes the request. Confirmed effects include terminating Workflows in other namespaces, registering namespaces, modifying another namespace's configuration, and deleting another namespace and its Workflows. The affected routing logic is present in both the HSM and CHASM callback delivery implementations. This description and the CVSS score in this record describe releases 1.30.0 and later, where any non-empty source header is sufficient. Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect in which the header must exactly match a configured cluster ID, a UUID that a namespace-scoped caller cannot read through the API. The consequence once that match occurs is the same, but the attack is materially harder and scores lower. To determine whether a deployment is affected, check two settings together: the static Server configuration for a non-zero services.internal-frontend.rpc.httpPort, and the effective per-namespace dynamic configuration value of component.callbacks.allowedAddresses. A deployment is exposed only when an internal frontend is deployed with a non-zero HTTP port, at least one allowlist rule admits a host, and authorization is enabled. The allowlist is empty by default, which denies all external callback URLs, and the stock static topology does not include an internal frontend. Note that a failed attach returns the error 'invalid url: url does not match any configured callback address', which proves only that one tested URL did not match and does not prove the effective allowlist is empty. To look for callbacks already attached, use DescribeWorkflowExecution, which returns callback information for a Workflow's registered completion callbacks. Operators should be aware of a gap when searching for evidence of delivery: the frontend HTTP API server records the request method and URL at debug level only, so at default log levels a delivered request is not written to the internal frontend's logs, and the absence of such log entries is not evidence that the issue was not exploited.•CVE-2026-87858
  2. In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.•CVE-2026-43500
  3. In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().•CVE-2026-43284
  4. Linux Kernel Incorrect Resource Transfer Between Spheres Vulnerability•CVE-2026-31431
  5. Microsoft Defender Insufficient Granularity of Access Control Vulnerability•CVE-2026-33825

References

Sources include official advisories and independent security research.