OpenAM versions prior to 16.1.3 have an improper authorization vulnerability that allows delegated administrators with specific session-destroy privileges to terminate sessions outside their authorized realms. This occurs because the realm checks rely on the requester's realm rather than the target session's realm, enabling cross-realm session destruction.
OpenAM versions prior to 16.1.3 have an authorization bypass vulnerability in the sessions REST endpoint. This flaw allows attackers with delegated RealmAdmin privileges to query session information across tenant boundaries by specifying another realm in the _queryFilter parameter. Sensitive data such as usernames, universal IDs, and session handles can be disclosed. The vulnerability has a medium severity score of 6.9 (CVSS 4.0).
OpenAM versions before 16.1.3 have an improper authorization vulnerability in their OAuth2 Provider implementation. Specifically, PKCE enforcement is only applied to authorization requests with response_type exactly equal to 'code'. Hybrid OpenID Connect flows that include 'code token', 'code id_token', or 'code token id_token' do not have this enforcement, allowing intercepted authorization codes to be redeemed by attackers with any non-empty code_verifier.
OpenAM versions before 16.1.3 contain an open redirect vulnerability in the /oauth2/connect/endSession endpoint. This flaw allows unauthenticated attackers to supply an unverified id_token_hint, enabling redirection to any registered post-logout URI. The vulnerability can be exploited for phishing attacks that leverage the trust of the OpenAM host. The issue is classified as low severity with a CVSS 4.0 score of 2.3.
OpenAM versions before 16.1.3 have an email content injection vulnerability that allows unauthenticated attackers to manipulate notification emails sent via the forgotPassword and register actions. Attackers can control the subject and message fields, enabling phishing attacks from the organisation's configured From address or use the register function to relay emails to arbitrary recipients. This vulnerability has a medium severity rating with a CVSS score of 5.3.
OpenAM versions prior to 16.1.3 contain a latent cross-site scripting (XSS) vulnerability. This flaw involves improper neutralization of input during web page generation, where the SAML message, relay state, and target URL are inserted unencoded into a cookie bounce auto-submit page. Exploitation requires the cookieHashRedirectEnabled setting to be enabled. However, an unrelated HTTP 500 error currently prevents exploitation in released versions.
OpenAM versions prior to 16.1.3 have a vulnerability in the legacy JAX-RPC SOAP interface that allows unauthenticated remote attackers to instantiate arbitrary classes. This flaw enables attackers to send SOAP requests with unverified session identifiers and chosen class names, potentially crashing the server, probing the classpath, or achieving code execution via gadget chains. The vulnerability has a high severity score of 8.8 (CVSS 4.0).
OpenAM versions before 16.1.3 have a reflected cross-site scripting (XSS) vulnerability. This flaw allows unauthenticated attackers to inject malicious scripts via crafted parameters on the OAuth2 authorization error page. Exploitation requires tricking users into visiting a specially crafted URL, enabling script execution in the context of the OpenAM origin. This can lead to actions within existing user sessions or redirection to phishing sites.
Nezha Dashboard versions from 1.8.0 up to but not including 2.3.13 have an improper locking vulnerability. This flaw involves a non-deferred mutex unlock that leaks on a nil-map panic path. An authenticated non-admin user can exploit this by issuing four notification API calls, causing a permanent deadlock in the alerting subsystem and subsequently exhausting memory with blocking requests. The vulnerability has a CVSS 4.0 score of 7.1, indicating high severity.
Nezha versions from 1.8.0 up to but not including 2.3.13 contain a race condition due to a lock-order inversion in the UpdateGroup and DeleteGroup functions. This flaw allows authenticated non-admin users to cause a deadlock in the alerting subsystem by concurrently invoking notification-group and batch-delete endpoints with oversized ID lists. The deadlock can permanently disrupt alert delivery until the system is restarted.
CWE-306: Missing Authentication for Critical Function in the ait.core.server telemetry and command broker (ait-server) in NASA-AMMOS AIT-Core through 3.1.1 allows an unauthenticated remote attacker with network access to the ZeroMQ message bus to inject spacecraft command data, exfiltrate command and telemetry traffic, inject forged telemetry, or disrupt the command and telemetry bus. The ait-server ZeroMQ broker binds its XSUB and XPUB sockets to all network interfaces by default without authentication or transport security. An attacker able to reach TCP port 5559 can publish messages onto internal topics, including the __commands__ command topic. With the shipped default configuration, command messages are forwarded through command_stream and emitted on the command-uplink UDP path. An attacker able to reach TCP port 5560 can subscribe to command and telemetry traffic on the ground bus. AIT-Core 3.1.2 changes the default ZeroMQ bind addresses to loopback.
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (c0f6ddfc6a324d42219bbea8405be17115f83eca0e2d2eecb4e3fe6b6ec3dbde)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
Fortra has released patches for eight vulnerabilities in its Core Privileged Access Manager (BoKS), including three critical flaws. These vulnerabilities include an authentication bypass due to predictable password generation, a command injection vulnerability allowing root shell command execution, and a stack buffer overflow causing memory corruption. The issues affect BoKS deployments managing Active Directory service accounts and components accessible over the network. No exploitation in the wild has been reported. The vendor has issued patches addressing these vulnerabilities.
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (5050cd1cac91a217e828de6f54792051b810c43bf9ee5d53e913479fb059715c)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
This content discusses a user-developed implementation of the Ascon lightweight cryptography algorithm, which is the NIST-selected standard for constrained environments. The user created a library and demo tools to provide a more general-purpose and spec-compliant Ascon implementation than the original reference code. The post is informational and does not report any vulnerability or exploit. NIST finalized Ascon as a standard in August 2025 with no known security issues reported here.
In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. Those arrays are read-only to the native code, and on a JVM that returns a copy rather than a pin the copy still holds the input bytes as they were read. The output buffer is taken through a separate critical region and committed first, so where an application passed the same Java array as both an input and the destination - encrypting in place over KeyParameter.getKey(), for example - the later mode-0 release of the key wrote the unchanged key bytes over the ciphertext that had just been produced. The call still returned the correct output length, so an application encrypting in place over its own key array was handed the raw AES key where it expected ciphertext, with nothing in the API to indicate it, and would transmit or store the key in place of the message. The read-only input arrays are now released with JNI_ABORT, freeing the native copy without copying it back, and mode 0 is reserved for arrays the native code wrote. The pure-Java packet ciphers and the streaming native modes are not affected. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
Bouncy Castle for Java versions before 1.86 and before 2.73.13 in the LTS branch contain a vulnerability in their legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 password-based encryption (PBE) implementations. These implementations accept an iteration count for key derivation from untrusted input without proper bounds checking, allowing a small input to cause an arbitrary amount of computational work before verification. This can lead to denial-of-service conditions due to excessive CPU usage. The issue is addressed by bounding iteration counts under a configurable property and rejecting out-of-range values.
Bouncy Castle for Java versions before 1.86 contain a vulnerability in the OpenPGP certificate API where third-party certifications or trust delegations could be accepted from subkeys lacking proper certification authority flags. This flaw allows a subkey without the CERTIFY_OTHER flag to issue valid-looking certifications or trust delegations, misleading applications into trusting attacker-controlled identities. The vulnerability does not forge primary key signatures or expose private keys but elevates the authority of compromised subkeys, undermining key-flag based containment. The issue is fixed by requiring that only the primary key or subkeys with the CERTIFY_OTHER flag can issue third-party certifications or delegations. No known exploits are reported in the wild.
Bouncy Castle for Java versions before 1.86 contain a vulnerability where truncated OpenPGP encrypted messages are accepted without error, leading to missing integrity checks on certain decryption paths. On the SEIPD version 1 path, this results in plaintext being delivered without any integrity verification, allowing altered ciphertext to produce accepted but modified plaintext. On the AEAD path, truncated chunks cause silent dropping of subsequent packets without error, potentially causing signed and encrypted messages to be read as unsigned. The low-level API remains unaffected if PGPEncryptedData.verify() is called directly. This issue also affects certain LTS and FIPS versions on the AEAD route. The vulnerability is a residual effect of a previous CVE and has been addressed in version 1.86 and later.