Security
Headlines
HeadlinesLatestCVEs

Latest News

GHSA-486g-47cc-8wxf: aiocpa contains credential harvesting code

aiocpa is a user-facing library for generating color gradients of text. Version 0.1.13 introduced obfuscated, malicious code targeting Crypto Pay users, forwarding client credentials to a remote Telegram bot. All versions have been removed from PyPI.

ghsa
#vulnerability#web#auth
GLASSBRIDGE: Google Blocks Thousands of Pro-China Fake News Sites

Google reveals GLASSBRIDGE: A network of thousands of fake news sites pushing pro-China narratives globally. These sites, run by PR firms, spread disinformation and lack transparency.

Ransomware Attack on Blue Yonder Hits Starbucks, Supermarkets

The incident is typical of the heightened threats organizations face during the holidays, when most companies reduce their security operations staff by around 50%.

Phishing Prevention Framework Reduces Incidents by Half

The anti-fraud plan calls for companies to create a pipeline for compiling attack information, along with formal processes to disseminate that intelligence across business groups.

BlackBasta Ransomware Brand Picks Up Where Conti Left Off

New analysis says law enforcement efforts against Russian-language ransomware-as-a-service (RaaS) infrastructure helped consolidate influence behind BlackBasta, but some experts aren't so sure the brand means that much.

GHSA-93ww-43rr-79v3: Keycloak mTLS Authentication Bypass via Reverse Proxy TLS Termination

A vulnerability was found in Keycloak. Deployments of Keycloak with a reverse proxy not using pass-through termination of TLS, with mTLS enabled, are affected. This issue may allow an attacker on the local network to authenticate as any user or client that leverages mTLS as the authentication mechanism.

GHSA-jgwc-jh89-rpgq: Keycloak proxy header handling Denial-of-Service (DoS) vulnerability

Keycloak versions 26 and earlier are vulnerable to a denial-of-service (DoS) attack through improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers. For Keycloak version 26, for successful exploitation includes: the realm must have SslRequired=EXTERNAL (the default), HTTP must be enabled, the instance must not be using a full hostname URL, access must come from behind a proxy (assuming the proxy overwrites the X-Forwarded-For header), and trusted proxies must not be set or must incor...

GHSA-xg58-75qf-9r67: Cilium's Layer 7 policy enforcement may not occur in policies with wildcarded port ranges

### Impact For users with the following configuration: * An allow policy that selects a [Layer 3 destination](https://docs.cilium.io/en/v1.14/security/policy/language/#layer-3-examples) and a [port range](https://docs.cilium.io/en/stable/security/policy/language/#example-port-ranges) **AND** * A [Layer 7 allow policy](https://docs.cilium.io/en/latest/security/policy/language/#layer-7-examples) that selects a specific port within the first policy's range then Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy. This issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16. For reference, an example of a pair of policies that would trigger this issue is: ``` apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "l3-port-range-rule" spec: endpointSelector: matchLabels: app: service ingress: - fromCIDR: - 192.168.60.0/24 toPorts: - ports: - port...

GHSA-qqwr-j9mm-fhw6: deno_doc's HTML generator vulnerable to Cross-site Scripting

### Summary Several cross-site scripting vulnerabilities existed in the `deno_doc` crate which lead to Self-XSS with `deno doc --html`. ### Details & PoC 1.) XSS in generated `search_index.js` `deno_doc` outputed a JavaScript file for searching. However, the generated file used `innerHTML` on unsanitzed HTML input. https://github.com/denoland/deno_doc/blob/dc556c848831d7ae48f3eff2ababc6e75eb6b73e/src/html/templates/pages/search.js#L120-L144 2.) XSS via property, method and enum names `deno_doc` did not sanitize property names, method names and enum names. ### Impact The first XSS most likely didn't have an impact since `deno doc --html` is expected to be used locally with own packages.

Cyber Resiliency in the AI Era: Building the Unbreakable Shield 

Digital networks are the backbone of global business and communication, making cyber resiliency essential for organizations to thrive.…