Latest News

Hacker claims to have breached OmniGPT, leaking over 30,000 user email address, phone numbers, and 34 million lines of chat messages. Data includes API keys, credentials, and file links.

But there's plenty in it — including two zero-days — that need immediate attention.

The vulnerability could allow a threat actor to disable the security feature on a locked device and gain access to user data.

The staffers were tasked with building relationships on the ground across the country in local election jurisdictions, teaching election officials tactics on mitigating cyber threats, cyber hygiene, combating misinformation and foreign influence, and more.

Microsoft has released its monthly security update for January of 2025 which includes 58 vulnerabilities, including 3 that Microsoft marked as “critical” and one marked as "moderate". The remaining vulnerabilities listed are classified as “important.”

Adobe Commerce versions 2.4.7-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue does not require user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.

Apache NiFi 1.16.0 through 1.28.0 and 2.0.0-M1 through 2.0.0-M4 include optional debug logging of Parameter Context values during the flow synchronization process. An authorized administrator with access to change logging levels could enable debug logging for framework flow synchronization, causing the application to write Parameter names and values to the application log. Parameter Context values may contain sensitive information depending on application flow configuration. Deployments of Apache NiFi with the default Logback configuration do not log Parameter Context values. Upgrading to Apache NiFi 2.0.0 or 1.28.1 is the recommendation mitigation, eliminating Parameter value logging from the flow synchronization process regardless of the Logback configuration.

### Impact Applications which have been bootstrapped by the new igniter installer (since AshAuthentication v4.1.0) and who have used the magic link strategy _or_ are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. If you did not use the new installer, then you are absolutely not affected. Additionally, unless you have implemented any kind of custom token revocation feature in your application (in which case even cursory testing would have uncovered this issue), then you will not be significantly affected. The impact here for users using builtin functionality is that magic link tokens are reusable until they expire instead of being immediately revoked. Magic link tokens are only valid for 10 minutes, so the surface area for abuse is extremely low here. ### Patches The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so if you u...

pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.

### Impact Systems running registry version > `3.0.0-beta.1` with token authentication enabled. ### Patches Update to at least `v3.0.0-rc.3` ### Workarounds There is no way to work around this issue without patching if your system requires token authentication. ### References The issue lies in how the JWK verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (`kid`) matches one of the trusted keys, but doesn't verify that the actual key material matches. Here's the problematic flow: 1. An attacker generates their own key pair 2. They create a JWT and include their public key in the JWK header 3. They set the `kid` in the JWK to match one of the trusted keys' IDs (which they could potentially discover) 4. They sign the JWT with their private key 5. The registry only checks if the `kid` exists in the trusted keys map but then uses the attacker's public key from the JWK to verify the signature