Security
Headlines
HeadlinesLatestCVEs

Tag

#oauth

Active Directory Under Siege: Why Critical Infrastructure Needs Stronger Security

Active Directory remains the authentication backbone for over 90% of Fortune 1000 companies. AD's importance has grown as companies adopt hybrid and cloud infrastructure, but so has its complexity. Every application, user, and device traces back to AD for authentication and authorization, making it the ultimate target. For attackers, it represents the holy grail: compromise Active

The Hacker News
#vulnerability#google#microsoft#git#backdoor#oauth#auth#The Hacker News
GHSA-38jw-g2qx-4286: KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ It was discovered that the `virt-api` component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the `extension-apiserver-authentication` configmap. The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the `virt-api` server using a certificate signed by the CA specified via the `--requestheader-client-ca-file` CLI flag. This CA bundle is primarily used in the context of aggr...

GHSA-jqmq-fpwv-p925: Drupal Simple OAuth (OAuth2) & OpenID Connect allows Authentication Bypass

Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal Simple OAuth (OAuth2) & OpenID Connect allows Authentication Bypass. This issue affects Simple OAuth (OAuth2) & OpenID Connect: from 6.0.0 before 6.0.7.

GHSA-mxxr-jv3v-6pgc: FastMCP vulnerable to reflected XSS in client's callback page

### Summary While setting up an oauth client, it was noticed that the callback page hosted by the client during the flow embeds user-controlled content without escaping or sanitizing it. This leads to a reflected Cross-Site-Scripting vulnerability. ### Details The affected code is located in *https://github.com/jlowin/fastmcp/blob/main/src/fastmcp/client/oauth_callback.py*, which embeds all values passed to the `create_callback_html` function via the `message` parameter it into the callback page without escaping them. This can, for example, be abused by calling the callback server with an XSS payload inside the `error` GET parameter, the value of which will then be inserted into the callback page, causing the execution of attacker-controlled JavaScript code in the callback server's origin. Note that besides the `error` parameter, other parameters reaching this function are affected too. ### PoC 1. Setup a simple fastmcp client such as this one (the callback server's port was fixated ...

GHSA-c2jp-c369-7pvx: FastMCP Auth Integration Allows for Confused Deputy Account Takeover

### Summary FastMCP documentation [covers the scenario](https://gofastmcp.com/integrations/azure) where it is possible to use Entra ID or other providers for authentication. In this context, because Entra ID does not support Dynamic Client Registration (DCR), the FastMCP-hosted MCP server is acting as the authorization provider, as declared in the Protected Resource Metadata (PRM) document hosted on the server. For example, on a local MCP server, it may be hosted here: ```http http://localhost:8000/.well-known/oauth-protected-resource ``` And the JSON representation of the PRM document: ```json { "resource": "http://localhost:8000/mcp", "authorization_servers": [ "http://localhost:8000/" ], "scopes_supported": [ "User.Read", "email", "openid", "profile" ], "bearer_methods_supported": [ "header" ] } ``` Notice that the `authorization_servers` field contains the MCP server itself - it acts as an **OAuth Client** to the downstream authorization ...

Is Your Google Workspace as Secure as You Think it is?

The New Reality for Lean Security Teams If you’re the first security or IT hire at a fast-growing startup, you’ve likely inherited a mandate that’s both simple and maddeningly complex: secure the business without slowing it down. Most organizations using Google Workspace start with an environment built for collaboration, not resilience. Shared drives, permissive settings, and constant

⚡ Weekly Recap: WSUS Exploited, LockBit 5.0 Returns, Telegram Backdoor, F5 Breach Widens

Security, trust, and stability — once the pillars of our digital world — are now the tools attackers turn against us. From stolen accounts to fake job offers, cybercriminals keep finding new ways to exploit both system flaws and human behavior. Each new breach proves a harsh truth: in cybersecurity, feeling safe can be far more dangerous than being alert. Here’s how that false sense of security

GHSA-5qjg-9mjh-4r92: Karmada Dashboard API Unauthorized Access Vulnerability

### Impact This is an authentication bypass vulnerability in the Karmada Dashboard API. The backend API endpoints (e.g., /api/v1/secret, /api/v1/service) did not enforce authentication, allowing unauthenticated users to access sensitive cluster information such as Secrets and Services directly. Although the web UI required a valid JWT for access, the API itself remained exposed to direct requests without any authentication checks. Any user or entity with network access to the Karmada Dashboard service could exploit this vulnerability to retrieve sensitive data. ### Patches The issue has been fixed in Karmada Dashboard v0.2.0. This release enforces authentication for all API endpoints. Users are strongly advised to upgrade to version v0.2.0 or later as soon as possible. ### Workarounds If upgrading is not immediately feasible, users can mitigate the risk by: - Restricting network access to the Karmada Dashboard service using Kubernetes Network Policies, firewall rules, or ingress con...

ThreatsDay Bulletin: $176M Crypto Fine, Hacking Formula 1, Chromium Vulns, AI Hijack & More

Criminals don’t need to be clever all the time; they just follow the easiest path in: trick users, exploit stale components, or abuse trusted systems like OAuth and package registries. If your stack or habits make any of those easy, you’re already a target. This week’s ThreatsDay highlights show exactly how those weak points are being exploited — from overlooked

GHSA-m732-5p4w-x69g: Hono Improper Authorization vulnerability

### Improper Authorization in Hono (JWT Audience Validation) Hono’s JWT authentication middleware did not validate the `aud` (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up). The issue is addressed by adding a new `verification.aud` configuration option to allow RFC 7519–compliant audience validation. This change is classified as a **security hardening improvement**, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification. ### Recommended secure configuration You can enable RFC 7519–compliant audience validation using the new `verification.aud` option: ```ts import { Hono } from 'hono' import { jwt } from 'hono/jwt' const app = new Hono() app.use( '/api/*', jwt({ secret: 'my-secret', verification: { // Require this API to only accep...