ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token because OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.
Apollo ConfigService versions prior to 2.5.2 contain an improper input validation vulnerability that may allow unauthorized access to raw configuration data. The issue arises because requests to the /configfiles/raw/{appId}/{clusterName}/{namespace} endpoint are incorrectly parsed for authentication, causing the service to verify the wrong appId and potentially bypass signature verification. This vulnerability is fixed in version 2.5.2.
Apollo ConfigService versions prior to 2.5.2 have an improper input validation vulnerability that may allow unauthorized access to configuration data when AccessKey or management key authentication is enabled. The issue arises because ConfigService accepts non-canonical appId variants during authentication, which downstream request handling resolves to protected applications. This includes variants with accent-insensitive collations or trailing spaces on the /configs and /configfiles endpoints. The vulnerability is fixed in version 2.5.2.
CVE-2026-15557 is an improper authentication vulnerability in waooAI waoowaoo affecting versions 0.4.0 and 0.4.1. The issue arises from manipulation of the x-internal-user-id request argument in several authentication-related functions within the Internal Task Header Handler component. This flaw allows remote attackers to bypass authentication mechanisms. The vulnerability has a medium severity rating with a CVSS score of 6.9. No official patch or remediation has been released yet, and the vendor has not responded to the issue report. Exploit code is publicly available, but no known exploitation in the wild has been reported.
The charging station does not require authentication for Bluetooth commands to perform actions. The functionality exposed includes sensitive information leakage, triggering reboots, or pushing a firmware update URL.
A vulnerability has been found in will-moss Isaiah up to 1.36.9. This affects an unknown function of the file app/main.go of the component Websocket Connection Authentication. The manipulation leads to improper authentication. The attack can be initiated remotely. The pull request to fix this issue awaits acceptance.
The Tutor LMS WordPress plugin before 3.9.13 does not, in its Droip and Kirki page-builder integration, perform the enrollment, purchase, and private-course capability checks it enforces in its core course handler, allowing authenticated users with subscriber-level access to enroll in paid or private courses without authorization, read private course content, and mark arbitrary courses as completed, on sites where the Droip or Kirki integration is active.
The User Registration & Membership WordPress plugin before 5.2.2 does not verify the authenticity of incoming payment-provider webhook notifications before acting on them, allowing unauthenticated attackers to forge a payment-approved event and activate a paid membership subscription without completing a real payment.
The miniOrange Social Login and Register (Discord, Google, Twitter, LinkedIn) plugin for WordPress is vulnerable to authentication bypass leading to account takeover in versions up to and including 7.7.0. This is due to the Profile Completion flow accepting an arbitrary email address via the 'email_field' POST parameter without verifying that the email belongs to the identity returned by the OAuth provider, combined with send_otp_token() returning the SHA-512(customer_key || otp) transaction hash to the client where the OTP space is only 99,000 values (wp_rand(1000, 99999)) and the customer_key is a static option (empty on unregistered installs). This makes it possible for unauthenticated attackers to trigger an OTP email to an arbitrary admin's address, crack the OTP offline from the leaked hash in under a second, and submit the cracked OTP to mo_openid_social_login_validate_otp(), which logs the attacker in as the user whose email was supplied — granting full administrator access.
RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0.
## SAML Tenant Binding Enables Cross-Tenant Account Takeover
### Summary
Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain.
In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant.
The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because `SAMLConfiguration.email_domain` and `SAMLDomainIndex.email_domain` are globally unique.
### Details
The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain:
```python
email_domain = user.email.split("@")[-1]
tenant = (
SAMLConfiguration.objects.using(MainRouter.admin_db)
.get(email_domain=email_domain)
.tenant
)
```
This is unsafe because `user.email` is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain.
The attack is made possible by several compounding weaknesses:
1. **No domain ownership proof** (`api/src/backend/api/models.py:2100, 2130-2152`): `SAMLConfiguration.email_domain` is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant.
2. **Global SAML domain index** (`api/src/backend/api/models.py:2200-2201`): `SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant})` maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route.
3. **Hardcoded auto-connect** (`api/src/backend/config/settings/social_login.py:23, 25`): `SOCIALACCOUNT_EMAIL_AUTHENTICATION = True` and `SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True` are hardcoded and cannot be disabled at runtime.
4. **IdP-initiated SSO enabled** (`api/src/backend/config/settings/social_login.py:78`): `reject_idp_initiated_sso: False` allows the attacker to initiate the flow without requiring any action from the victim.
5. **Token issuance for the wrong tenant** (`api/src/backend/api/v1/views.py:853-873`): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a `SAMLToken` using a tenant derived from the asserted email domain instead of the validated SAML configuration.
6. **Token switch impact** (`api/src/backend/api/v1/serializers.py:272`): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.
### PoC
**Environment setup:**
```bash
# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .
# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit
```
**Automated test (runs inside the container):**
```bash
python -m pytest poc_vuln001.py -v -s --no-header --tb=short
```
**Manual HTTP exploitation chain (against a live Prowler API):**
**Step 1 - Attacker configures SAML for their own email domain:**
```bash
curl -i -X POST "$API/api/v1/saml-config" \
-H "Authorization: Bearer $ATTACKER_TOKEN" \
-H "Content-Type: application/vnd.api+json" \
--data '{
"data":{"type":"saml-configurations","attributes":{
"email_domain":"attacker.com",
"metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
}}
}'
```
The attacker does not need to claim `victim.com`. If `victim.com` is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.
**Step 2 - Attacker posts a signed SAMLResponse asserting `user@victim.com`:**
```bash
# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
-X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
--data-urlencode "SAMLResponse=$SIGNED_ASSERTION"
```
**Step 3 - Vulnerable ACS finish logic derives
9Router is an AI router & token saver. Prior to 0.5.2, 9router treats loopback requests as trusted and allows /v1/* access without an API key, so a same-host reverse proxy that forwards public traffic to the backend through 127.0.0.1 causes src/dashboardGuard.js to misclassify external requests as local. A remote unauthenticated attacker can access /v1 APIs such as /v1/models and may abuse configured upstream provider credentials through /v1 proxy endpoints depending on enabled providers. This issue is fixed in version 0.5.2.
The LoginPress Pro plugin for WordPress is vulnerable to authentication bypass in versions up to and including 6.2.3 via the Spotify Social Login addon. This is due to the loginpress_on_spotify_login() function trusting the unverified 'email' field returned by Spotify's /v1/me endpoint and using it directly with get_user_by('email', $profile['email']) to identify and log in an existing WordPress account, without confirming that the Spotify user actually owns the email address (Spotify documents that the profile email is unverified) and without requiring the user to prove ownership of the matching WordPress account. This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including Administrators, by registering a Spotify account using the targeted user's email address and authenticating via the Spotify provider.