#vulnerability

Zoom and GitLab have released security updates to resolve a number of security vulnerabilities that could result in denial-of-service (DoS) and remote code execution. The most severe of the lot is a critical security flaw impacting Zoom Node Multimedia Routers (MMRs) that could permit a meeting participant to conduct remote code execution attacks. The vulnerability, tracked as CVE-2026-22844

Improper input handling in the JSON deserialization component can lead to arbitrary JavaScript code execution. The vulnerability can be exploited via overriding constant value and error deserialization, which allows indirect access to unsafe JS evaluation. This requires at least the ability to perform 4 separate requests on the same function and partial knowledge of how the serialized data is used during later runtime processing. This vulnerability affects the `fromJSON` and `fromCrossJSON` functions in a client-to-server transmission scenario. No known workarounds or mitigations are known, so please upgrade to the patched version.

### Impact This vulnerability affects Laravel Reverb versions prior to v1.7.0 when horizontal scaling is enabled (`REVERB_SCALING_ENABLED=true`). The exploitability of this vulnerability is increased because Redis servers are commonly deployed without authentication. With horizontal scaling enabled, Reverb servers communicate via Redis PubSub. Reverb previously passed data from the Redis channel directly into PHP’s `unserialize()` function without restricting which classes could be instantiated. **Risk:** Remote Code Execution (RCE) ### Patches This vulnerability is fixed in Laravel Reverb v1.7.0. Update your dependency to `laravel/reverb: ^1.7.0` immediately. ### Workarounds If you cannot upgrade to v1.7.0, you should apply the following mitigations: * Redis Security: Require a strong password for Redis access and ensure the service is only accessible via a private network or local loopback. * Disable Scaling: If your environment uses only one Reverb node, set `REVERB_SCALING_...

Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components.  Only deployments that meet all of the following criteria are impacted by this vulnerability: * Use of Solr's "RuleBasedAuthorizationPlugin" * A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles" * A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read". * A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission * A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening pro...

The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.ap...

A flaw was found in the Keycloak Admin REST API. This vulnerability allows the exposure of backend schema and rules, potentially leading to targeted attacks or privilege escalation via improper access control.

Researchers showed how prompt injection hidden in a calendar invite can bypass privacy controls and turn an AI assistant into a data-leaking accomplice.

A poorly secured wristband system used at a Carlsberg exhibition allowed access to visitor photos, videos, and full names. Attempts to report the issue were ignored for months.

Gartner® doesn’t create new categories lightly. Generally speaking, a new acronym only emerges when the industry's collective "to-do list" has become mathematically impossible to complete. And so it seems that the introduction of the Exposure Assessment Platforms (EAP) category is a formal admission that traditional Vulnerability Management (VM) is no longer a viable way to secure a modern

A flaw was found in the keycloak-services component of Keycloak. This vulnerability allows the issuance of access and refresh tokens for disabled users, leading to unauthorized use of previously revoked privileges, via a business logic vulnerability in the Token Exchange implementation when a privileged client invokes the token exchange flow.