| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Locust through 2.46.7 contains a cross-site request forgery vulnerability that allows remote attackers to stop load tests or reset statistics via GET requests to /stop and /stats/reset. Attackers can lure an operator to a malicious page triggering cross-site GET requests, terminating running swarms and wiping recorded performance results. |
| Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated. |
| undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata. |
| REDAXO is a PHP-based content management system. Prior to 5.21.2, rex_api_install_package_update in redaxo/src/addons/install/lib/api/api_package_update.php inherits the false default from rex_api_function::requiresCsrfProtection() instead of requiring a CSRF token. An unauthenticated attacker can cause a logged-in administrator's browser to request a selected package update from the configured REDAXO package server, changing installed addon code or disrupting the site without the administrator's intent. This issue is fixed in version 5.21.2. |
| In the Linux kernel, the following vulnerability has been resolved:
udf: reject descriptors with oversized CRC length
udf_read_tagged() skips CRC verification when descCRCLength +
sizeof(struct tag) exceeds the block size. A crafted UDF image can
set descCRCLength to an oversized value to bypass CRC validation
entirely; the descriptor is then accepted based solely on the 8-bit
tag checksum, which is trivially recomputable.
Reject such descriptors instead of silently accepting them. A
legitimate single-block descriptor should never have a CRC length that
exceeds the block. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Validate the passed in fops for ib_get_ucaps()
Sashiko pointed out it is not safe to rely only on the devt because
char/block alias so if the user finds a block device with the same dev_t
it can masquerade as a ucap cdev fd.
Test the f_ops to only accept authentic cdevs. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5enc - fix async decrypt skipping hash verification
krb5enc_dispatch_decrypt() sets req->base.complete as the skcipher
callback, which is the caller's own completion handler. When the
skcipher completes asynchronously, this signals "done" to the caller
without executing krb5enc_dispatch_decrypt_hash(), completely bypassing
the integrity verification (hash check).
Compare with the encrypt path which correctly uses
krb5enc_encrypt_done as an intermediate callback to chain into the
hash computation on async completion.
Fix by adding krb5enc_decrypt_done as an intermediate callback that
chains into krb5enc_dispatch_decrypt_hash() upon async skcipher
completion, matching the encrypt path's callback pattern.
Also fix EBUSY/EINPROGRESS handling throughout: remove
krb5enc_request_complete() which incorrectly swallowed EINPROGRESS
notifications that must be passed up to callers waiting on backlogged
requests, and add missing EBUSY checks in krb5enc_encrypt_ahash_done
for the dispatch_encrypt return value.
Unset MAY_BACKLOG on the async completion path so the user won't
see back-to-back EINPROGRESS notifications. |
| A security flaw has been discovered in aircheng-org iWebShop-5 up to 5.16. The affected element is the function admin_repwd/admin_repwd_act of the file controllers/system.php of the component Password Change. The manipulation of the argument password/repassword results in cross-site request forgery. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| A security flaw has been discovered in dyad-sh dyad up to 1.16.0. Affected by this issue is some unknown functionality of the component OAuth Callback Handler. Performing a manipulation results in cross-site request forgery. The attack may be initiated remotely. Upgrading to version 1.17.0-beta.1 can resolve this issue. The patch is named 39fbae87b38573616a1a3b152cdb292787bb1109. It is advisable to upgrade the affected component. |
| Cross-Site Request Forgery (CSRF) vulnerability in Apache Camel OAuth component.
This issue affects Apache Camel: from 4.11.0 before 4.18.5, from 4.19.0 before 4.22.1.
The authorization code callback did not carry a state parameter binding it to the authorization request that started the flow, and the callback did not verify one. An authorization code obtained in any browser could therefore be redeemed at the callback and associated with whichever session presented it, which is login cross-site request forgery: a victim can be silently signed in as an identity the attacker controls, so that actions the victim then performs, and data they then submit, land in the attacker's account. The same unvalidated callback handling also allowed the post-authentication redirect target to be influenced, giving an open redirect from a trusted origin. The state check runs before the authorization code is redeemed, so these paths are reachable without any interaction with the identity provider.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The authorization request now issues a state value bound to the session, and the callback rejects a request whose state is absent or does not match, stopping the route with a 400 response. For deployments that cannot upgrade immediately, terminate the authorization code flow in a component that performs its own state binding rather than relying on the Camel callback. Note that after upgrading, a deployment behind a proxy that drops or rewrites the callback query string will begin to see 400 responses, because the state parameter must survive the round trip. |
| Gitify before 7.10.0 contains a login cross-site request forgery vulnerability that allows remote attackers to bind a victim's client to their account because performGitHubWebOAuth() omits OAuth state validation. Attackers can get a gitify://oauth?code= link with their own authorization code opened during a victim's pending login, causing Gitify to display attacker-controlled notifications as the victim's own. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task
and copies the PDU's data segment into that command's scatterlist without
asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same
file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE.
A target that answers a WRITE command's ITT with a Data-In therefore has
the initiator write target-supplied bytes into the pages that write was
about to send. Those are the caller's own pinned pages for an O_DIRECT
write, and page cache pages for a buffered one.
Observed against a test target that emits one 512-byte Data-In naming a 128
KB write's ITT, after the R2T for that write. With O_DIRECT the caller's
buffer ends up holding 512 bytes of the target's data while pwrite()
returns 131072. Buffered is quieter: pwrite() and fsync() both succeed,
nothing is logged, and reading those blocks back returns the target's bytes
out of the page cache without a command going on the wire.
Check the direction before using the scatterlist, the way the R2T path
already does. |
| Distribution is a toolkit to pack, ship, store, and deliver container content. Prior to 3.1.2, registry/client.(*manifests).Get() reads a manifest returned for a digest-pinned request and passes it to distribution.UnmarshalManifest without hashing the body against the requested digest, allowing a malicious or intercepted registry response to substitute attacker-chosen manifest content even when Docker-Content-Digest claims the requested value. The bundled pull-through proxy in registry/proxy/proxymanifeststore.go can cache and re-serve the substituted manifest. This issue is fixed in version 3.1.2. |
| The User Registration & Membership – Free & Paid Memberships, Subscriptions, Content Restriction, User Profile, Custom User Registration & Login Builder plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 5.2.8 This is due to missing or incorrect nonce validation on the trigger_bulk_action function. This makes it possible for unauthenticated attackers to force administrators to approve pending user registrations or deny arbitrary user accounts, locking targeted users out of the site via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. An attacker can bypass the earlier nonce check in trigger_query_actions() by supplying an empty new_role parameter, which causes that handler to return early and cede control to the unprotected trigger_bulk_action() handler; the exit() call at the end of that handler additionally prevents WordPress core's own bulk-users nonce validation from executing. |
| Traccar 5.7 through 6.16.0 contains a cross-site request forgery vulnerability that allows attackers to log victims into attacker-controlled accounts because the OpenID Connect callback never validates the OAuth state parameter. Attackers can induce a victim's browser to load /api/session/openid/callback with their own authorization code, causing data the victim enters, such as registered devices, to land in the attacker's account. |
| OpenRefine through 3.10.1 contains a cross-site request forgery vulnerability in the get-rows command that allows remote attackers to execute Jython facet expressions. Attackers can lure a user to a malicious page issuing a cross-origin GET with a crafted engine parameter, executing operating system commands as the OpenRefine user. |
| Python Social Auth is a social authentication/registration mechanism. Prior to 5.0.2, the LINE backend exchanges an authorization code without validating the returned OAuth state. An attacker can begin authorization for an attacker-controlled LINE account and induce a victim to visit the resulting callback URL, causing the application to log the victim into the attacker's account. When account linking is enabled, the same missing validation can link the attacker's LINE identity to the victim's existing account and create a persistent unauthorized login path. Only applications with the LINE backend enabled are affected. This issue is fixed in version 5.0.2. |
| In Eclipse Jetty, across various versions of `jetty-security`, and `jetty-eeN-security`, and `jetty-eeN-servlet`, the Jakarta Spec constraints defined as `http-method-omission` can be bypassed by using substrings of the defined HTTP Methods. |
| Exposure of private personal information to an unauthorized actor in Azure Active Directory allows an unauthorized attacker to disclose information locally. |
| XXL-JOB 3.5.0-SNAPSHOT and earlier contains a Cross-Site Request Forgery (CSRF) vulnerability in the user management controller (JobUserController). The endpoints /user/insert, /user/update, and /user/delete lack CSRF protection and do not restrict HTTP method. |
