| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Rodauth before 2.47.0 contains a time-based one-time password reuse vulnerability in the otp feature that fails to track the last accepted code timestamp. Attackers who observe a valid TOTP code can replay it during the drift window to bypass the second authentication factor. |
| Zephyr's WireGuard VPN data-plane receive handler wg_process_data_message() in subsys/net/lib/wireguard/wg_crypto.c validated the anti-replay counter too late. After AEAD decryption of a MESSAGE_TRANSPORT_DATA packet succeeded, the code committed several peer-state changes — update_peer_addr() (endpoint roaming update), the keypair->last_rx/peer->last_rx liveness timers, and keypair_update() (promote next→current and destroy the previous keypair) — and only afterward called wg_check_replay(). On a replayed packet the replay check returned -EINVAL, but none of the preceding mutations were rolled back.
The AEAD tag authenticates content but not freshness, so a replayed-but-authentic transport packet decrypts correctly. An attacker who captures one valid ciphertext off the wire (an on-path or shared-medium observer) can re-inject it from an arbitrary spoofed source address. Reaching the handler requires no credentials: it is driven directly from inbound UDP datagrams via the dispatch in subsys/net/lib/wireguard/wg.c.
Because the state mutations committed before the replay check, the replay repoints the peer endpoint to the attacker-chosen source address (roaming hijack), redirecting the victim's subsequent outbound tunnel traffic until the legitimate peer's next packet re-corrects it; it also prematurely destroys the previous keypair and refreshes the RX liveness timer. The tunnel payload stays encrypted under the session keypair, so this is an integrity/availability impact (traffic redirection and session disruption), not payload disclosure. The fix moves wg_check_replay() to immediately after a successful decrypt, before any peer-state mutation, matching the WireGuard specification and the Linux reference implementation. |
| An issue in Vanderbilt Industries, Acre Security SPC5300.000 Main Board v.3.14.1 allows a physically proximate attacker to cause a denial of service via the SPC Connect Pro software accepts replayed application-layer payloads injected into an active TCP session. |
| An issue in Vanderbilt Industries, Acre Security SPC5300.000 Main Board v.3.14.1 allows a physically proximate attacker to cause a denial of service via spoofed TCP FIN packets without validating the sequence or acknowledgment numbers. |
| Unauthenticated Other Vulnerability Type in Forminator <= 1.57.1 versions. |
| Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Through 1.5.0, the validity store uses a strict lower-bound comparison that expires a stored transaction too early relative to Transaction::is_valid_at, allowing a remote attacker to replay the same signed transaction during a blocks_per_batch minus one block window and cause the sender and recipient balances to be updated twice. This issue is fixed in version 1.5.1. |
| Authentication Bypass by Capture-replay vulnerability in Apache Tomcat's DIGEST authenticator. If, before windowSize requests have been made, a client makes a DIGEST
authenticated request with a nonceCount on the upper boundary of the
replay window then that request is replayable once only while the
associated nonceCount remains within the replay window.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120.
The following versions were EOL at the time the CVE was created but are
known to be affected: from 8.5.0 through 8.5.100, from 7.0.30 through 7.0.109. Other unsupported versions may also be affected.
Users are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue. |
| Authentication Bypass by Capture-replay vulnerability in Spring Spring Security allows Spring Security's DPoPProofJwtDecoderFactory contains a cache-based replay attack vulnerability. The internal cache storing JWT ID claims has a strict size limit, allowing attackers to evict legitimate entries by flooding the server with dummy requests, then replay intercepted valid DPoP proofs.
This issue affects Spring Security: 7.1.0, from 7.0.0 through 7.0.6, and from 6.5.0 through 6.5.11. |
| Etherpad is a real-time collaborative editor. From 2.6.0 until 3.1.0, Etherpad's src/node/hooks/express/tokenTransfer.ts uses POST /tokenTransfer to store an author token for transfer between browsers and exposes it through GET /tokenTransfer/{uuid}. Although the record includes createdAt, the transfer has no expiration check, is not removed after successful redemption, and is returned by res.send(tokenData), including the raw author token. An unauthenticated attacker who obtains a transfer UUID can repeatedly redeem it, receive fresh author cookies, read the cleartext token, and impersonate the originating author for pad read and write operations. This issue is fixed in version 3.1.0. |
| Authentication Bypass by Capture-replay vulnerability in dropbox samly allows an attacker to authenticate as the subject of a captured SAML assertion by resubmitting it.
Samly.Helper.decode_idp_auth_resp/3 in lib/samly/helper.ex calls esaml_sp:validate_assertion/2, whose default duplicate detector is a no-op. The /3 arity accepting a DuplicateFun exists in esaml and implements the check, but Samly never calls it and offers no configuration to supply one, so the SAML 2.0 Web Browser SSO Profile requirement that a bearer assertion be used once is unenforced. An attacker holding a valid SAMLResponse obtained from the network, from browser history, or from logs can submit the identical bytes repeatedly until the assertion's NotOnOrAfter passes, each time establishing a session as the assertion's subject.
This issue affects samly: from 0.3.0 onward. |
| BetterDesk is a remote desktop management solution. BetterDesk versions through 2.3.0 improperly invalidate deleted device identities, allowing an unauthenticated client to replay or spoof a device ID and bypass registration controls. Version 3.0.0-alpha contains a patch. No known workarounds are available. |
| phpMyFAQ before 4.1.7 fails to persist the WebAuthn login challenge generated by prepareForLogin, because neither WebAuthn controller saves the mutated key objects back to the database. At login the anti-replay comparison is skipped by its own null guard, allowing an attacker who captures a successful WebAuthn assertion to replay it indefinitely and authenticate as the user without any interaction or hardware key. |
| Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated remote client to obtain paid resources by resubmitting one settled on-chain transfer.
MPP.Methods.EVM.verify/2 accepts a transaction-hash credential and matches a transfer purely on token, to and amount (ERC-20) or to and value (native). It binds the proof neither to the challenge being verified nor to any record of prior use, and the generic MPP.Plug dedup store keys on challenge.id, which is regenerated for every 402 response. On a static-price route, a single historical transfer matching the charge therefore satisfies an unbounded number of later charges, including transfers an attacker can read off a public block explorer.
This issue affects mpp: from 0.3.0 before 0.6.3. |
| Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer.
MPP.Methods.Tempo normally binds a settled TIP-20 TransferWithMemo to the specific challenge under verification through an attribution nonce carried in the memo. When a static "memo" is configured in method_config, check_matched_memo_binding/3 returns the match unconditionally and that binding is skipped, leaving only token, recipient, amount and the static memo value to match on. The static memo is echoed in every unauthenticated 402 response and Tempo transfers are public, so an attacker can take any matching transfer paid by a legitimate customer, request a fresh challenge for the same route, and present that transaction hash as a type="hash" credential. The hash path performs no sender or signature check tying the presenter to the wallet that broadcast the transfer.
This issue affects mpp: from 0.6.1 before 0.6.4. |
| Laravel Socialite's Facebook provider contains an authentication bypass vulnerability that allows unauthenticated attackers to replay captured OIDC id_tokens by exploiting the missing nonce claim validation in the getUserByOIDCToken() function within FacebookProvider.php. Attackers who obtain a valid, unexpired id_token issued for the same Facebook App ID can submit the captured token to the backend userFromToken() endpoint, bypassing authentication controls because signature, aud, and iss checks pass while no session-bound nonce comparison is performed, resulting in unauthorized access to victim accounts. |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to perform unauthorized operations and access sensitive information due to improper session management. |
| Authentication bypass by capture-replay in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to bypass security restrictions due to improper validation of a session token. |
| Vulnerability-Lookup contains an
authentication weakness in its account activation and password-recovery
mechanism. Activation and recovery links were generated using stateless
signed tokens containing only the user's login. Although the token
signature and age were validated, the application did not track whether a
token had already been successfully used. As a result, a captured
activation or password-recovery link remained valid for the entire
configured TOKEN_VALIDITY_PERIOD, even after the associated password had been changed.
An attacker who obtains a valid
activation or recovery token could therefore replay it multiple times
during its validity period to set a new password and repeatedly take
control of the affected account. In addition, tokens were not bound to a
specific purpose, allowing the same token mechanism to be used across
activation and recovery workflows. The patch introduces purpose-bound
tokens and a random nonce whose SHA-256 digest is stored with the user
account. The nonce is invalidated after a successful password change,
making tokens single-use, while issuing a new token invalidates any
previously issued token. The password-setting operation now explicitly consumes the token before committing the account change.
Successful exploitation requires
the attacker to obtain a currently valid activation or recovery link,
but does not require knowledge of the victim's existing password or an
authenticated session. |
| Craft CMS before 5.10.5 fails to persist updated credential counters after WebAuthn assertion validation in the passkey login endpoint. Attackers can replay captured login request bodies containing requestOptions and response to create additional authenticated sessions for victim accounts. |
