CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1199 vulnerabilities reference this CWE, most recent first.
GHSA-9R3J-XMVW-9J69
Vulnerability from github – Published: 2025-04-10 09:30 – Updated: 2026-04-01 18:34Authentication Bypass by Spoofing vulnerability in Ays Pro Survey Maker allows Identity Spoofing. This issue affects Survey Maker: from n/a through 5.1.5.4.
{
"affected": [],
"aliases": [
"CVE-2025-32275"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-10T08:15:20Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass by Spoofing vulnerability in Ays Pro Survey Maker allows Identity Spoofing. This issue affects Survey Maker: from n/a through 5.1.5.4.",
"id": "GHSA-9r3j-xmvw-9j69",
"modified": "2026-04-01T18:34:39Z",
"published": "2025-04-10T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32275"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/survey-maker/vulnerability/wordpress-survey-maker-plugin-5-1-5-0-bypass-vulnerability-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9RF3-44G3-H94Q
Vulnerability from github – Published: 2024-12-27 21:30 – Updated: 2024-12-28 21:30An issue was discovered in Kurmi Provisioning Suite 7.9.0.33. If an X-Forwarded-For header is received during authentication, the Kurmi application will record the (possibly forged) IP address mentioned in that header rather than the real IP address that the user logged in from. This fake IP address can later be displayed in the My Account popup that shows the IP address that was used to log in.
{
"affected": [],
"aliases": [
"CVE-2024-54450"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T20:15:23Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in Kurmi Provisioning Suite 7.9.0.33. If an X-Forwarded-For header is received during authentication, the Kurmi application will record the (possibly forged) IP address mentioned in that header rather than the real IP address that the user logged in from. This fake IP address can later be displayed in the My Account popup that shows the IP address that was used to log in.",
"id": "GHSA-9rf3-44g3-h94q",
"modified": "2024-12-28T21:30:26Z",
"published": "2024-12-27T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54450"
},
{
"type": "WEB",
"url": "https://kurmi-software.com"
},
{
"type": "WEB",
"url": "https://kurmi-software.com/cve/cve-2024-54450"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9V5M-39WH-5CHQ
Vulnerability from github – Published: 2026-06-04 19:33 – Updated: 2026-06-04 19:33Summary
The Shopware Store API endpoint /store-api/handle-payment contains an object-level authorization flaw that allows a low-privileged external user with a normal customer or guest context to trigger the payment flow for another user’s order by supplying a foreign orderId. The affected functionality is the Store API payment initiation and retry flow. The root cause is that the endpoint forwards the user-controlled orderId into the payment processing logic without verifying that the caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows.
Description
Shopware exposes /store-api/handle-payment to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access guest orders after completing additional verification such as deepLinkCode, email address, and postal code. The Store API /store-api/order route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, /store-api/handle-payment does not follow the same protection model. It only checks whether the supplied orderId exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer’s order as long as they know a valid foreign order ID. Although orderId is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid orderId as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.
Expected Behavior
/store-api/handle-payment should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied orderId, the server should verify that the current SalesChannelContext belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected /store-api/order route.
Root Cause
The vulnerable endpoint accepts orderId, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.
#[Route(path: '/store-api/handle-payment', name: 'store-api.payment.handle', methods: ['GET', 'POST'])]
public function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse
{
$data = [...$request->query->all(), ...$request->request->all()];
$this->dataValidator->validate($data, $this->createDataValidation());
/** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */
$orderCurrencyId = $this->getCurrencyFromOrder($data['orderId'], $context->getContext());
if ($context->getCurrencyId() !== $orderCurrencyId) {
$context = $this->contextService->get(
new SalesChannelContextServiceParameters(
$context->getSalesChannelId(),
$context->getToken(),
$context->getLanguageId(),
$orderCurrencyId,
)
);
}
$response = $this->paymentProcessor->pay(
$data['orderId'],
$request,
$context,
$data['finishUrl'] ?? null,
$data['errorUrl'] ?? null,
);
return new HandlePaymentMethodRouteResponse($response);
}
File: src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php
The internal payment processing path similarly uses the supplied orderId to find the current transaction without checking whether the current caller owns the order.
public function pay(
string $orderId,
Request $request,
SalesChannelContext $salesChannelContext,
?string $finishUrl = null,
?string $errorUrl = null,
): ?RedirectResponse {
$transaction = $this->getCurrentOrderTransaction($orderId, $salesChannelContext->getContext());
if (!$transaction) {
return null;
}
$response = $paymentHandler->pay($request, $transactionStruct, $salesChannelContext->getContext(), $validationStruct);
return $response;
}
private function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity
{
$criteria = (new Criteria())
->addFilter(new EqualsFilter('stateId', $this->initialStateIdLoader->get(OrderTransactionStates::STATE_MACHINE)))
->addFilter(new EqualsFilter('orderId', $orderId))
->addSorting(new FieldSorting('createdAt', FieldSorting::DESCENDING))
->setLimit(1);
$transaction = $this->orderTransactionRepository->search($criteria, $context)->getEntities()->first();
if (!$transaction) {
$criteria->resetFilters();
$criteria->addFilter(new EqualsFilter('orderId', $orderId));
if ($this->orderTransactionRepository->searchIds($criteria, $context)->firstId()) {
return null;
}
throw PaymentException::invalidOrder($orderId);
}
return $transaction;
}
File: src/Core/Checkout/Payment/PaymentProcessor.php
By contrast, the official order retrieval route explicitly enforces current-context order ownership.
if ($context->getCustomer()) {
$criteria->addFilter(new EqualsFilter('order.orderCustomer.customerId', $context->getCustomerId()));
} elseif ($deepLinkFilter === null) {
throw OrderException::customerNotLoggedIn();
}
if ($deepLinkFilter !== null && !$context->getCustomer()) {
$order = $orders->first();
if ($order === null) {
throw OrderException::guestNotAuthenticated();
}
$this->guestAuthenticator->validate($order, $request);
}
File: src/Core/Checkout/Order/SalesChannel/OrderRoute.php
The Store API schema also reflects that /store-api/order is designed for customer-owned or guest-authenticated order access, while /store-api/handle-payment only requires orderId.
{
"summary": "Fetch a list of orders",
"description": "List orders of a customer."
}
File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json
{
"summary": "Initiate a payment for an order",
"required": ["orderId"]
}
File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json
The expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied orderId and allows a sensitive payment action on a foreign order.
Impact
The attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to /store-api/handle-payment in order to trigger the payment retry or payment initiation flow for another customer’s order. Here, orderId should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid orderId as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.
Patch Recommendation
Before processing a supplied orderId, /store-api/handle-payment should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by orderId; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48016"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T19:33:54Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Shopware Store API endpoint `/store-api/handle-payment` contains an object-level authorization flaw that allows a low-privileged external user with a normal customer or guest context to trigger the payment flow for another user\u2019s order by supplying a foreign `orderId`. The affected functionality is the Store API payment initiation and retry flow. The root cause is that the endpoint forwards the user-controlled `orderId` into the payment processing logic without verifying that the caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows.\n\n## Description\n\nShopware exposes `/store-api/handle-payment` to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access guest orders after completing additional verification such as `deepLinkCode`, email address, and postal code. The Store API `/store-api/order` route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, `/store-api/handle-payment` does not follow the same protection model. It only checks whether the supplied `orderId` exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer\u2019s order as long as they know a valid foreign order ID. Although `orderId` is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid `orderId` as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.\n\n### Expected Behavior\n\n`/store-api/handle-payment` should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied `orderId`, the server should verify that the current `SalesChannelContext` belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected `/store-api/order` route.\n\n### Root Cause\n\nThe vulnerable endpoint accepts `orderId`, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.\n\n```php\n#[Route(path: \u0027/store-api/handle-payment\u0027, name: \u0027store-api.payment.handle\u0027, methods: [\u0027GET\u0027, \u0027POST\u0027])]\npublic function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse\n{\n $data = [...$request-\u003equery-\u003eall(), ...$request-\u003erequest-\u003eall()];\n $this-\u003edataValidator-\u003evalidate($data, $this-\u003ecreateDataValidation());\n /** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */\n $orderCurrencyId = $this-\u003egetCurrencyFromOrder($data[\u0027orderId\u0027], $context-\u003egetContext());\n\n if ($context-\u003egetCurrencyId() !== $orderCurrencyId) {\n $context = $this-\u003econtextService-\u003eget(\n new SalesChannelContextServiceParameters(\n $context-\u003egetSalesChannelId(),\n $context-\u003egetToken(),\n $context-\u003egetLanguageId(),\n $orderCurrencyId,\n )\n );\n }\n\n $response = $this-\u003epaymentProcessor-\u003epay(\n $data[\u0027orderId\u0027],\n $request,\n $context,\n $data[\u0027finishUrl\u0027] ?? null,\n $data[\u0027errorUrl\u0027] ?? null,\n );\n\n return new HandlePaymentMethodRouteResponse($response);\n}\n```\n\nFile: `src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php`\n\nThe internal payment processing path similarly uses the supplied `orderId` to find the current transaction without checking whether the current caller owns the order.\n\n```php\npublic function pay(\n string $orderId,\n Request $request,\n SalesChannelContext $salesChannelContext,\n ?string $finishUrl = null,\n ?string $errorUrl = null,\n): ?RedirectResponse {\n $transaction = $this-\u003egetCurrentOrderTransaction($orderId, $salesChannelContext-\u003egetContext());\n if (!$transaction) {\n return null;\n }\n\n $response = $paymentHandler-\u003epay($request, $transactionStruct, $salesChannelContext-\u003egetContext(), $validationStruct);\n\n return $response;\n}\n\nprivate function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity\n{\n $criteria = (new Criteria())\n -\u003eaddFilter(new EqualsFilter(\u0027stateId\u0027, $this-\u003einitialStateIdLoader-\u003eget(OrderTransactionStates::STATE_MACHINE)))\n -\u003eaddFilter(new EqualsFilter(\u0027orderId\u0027, $orderId))\n -\u003eaddSorting(new FieldSorting(\u0027createdAt\u0027, FieldSorting::DESCENDING))\n -\u003esetLimit(1);\n\n $transaction = $this-\u003eorderTransactionRepository-\u003esearch($criteria, $context)-\u003egetEntities()-\u003efirst();\n\n if (!$transaction) {\n $criteria-\u003eresetFilters();\n $criteria-\u003eaddFilter(new EqualsFilter(\u0027orderId\u0027, $orderId));\n\n if ($this-\u003eorderTransactionRepository-\u003esearchIds($criteria, $context)-\u003efirstId()) {\n return null;\n }\n\n throw PaymentException::invalidOrder($orderId);\n }\n\n return $transaction;\n}\n```\n\nFile: `src/Core/Checkout/Payment/PaymentProcessor.php`\n\nBy contrast, the official order retrieval route explicitly enforces current-context order ownership.\n\n```php\nif ($context-\u003egetCustomer()) {\n $criteria-\u003eaddFilter(new EqualsFilter(\u0027order.orderCustomer.customerId\u0027, $context-\u003egetCustomerId()));\n} elseif ($deepLinkFilter === null) {\n throw OrderException::customerNotLoggedIn();\n}\n\nif ($deepLinkFilter !== null \u0026\u0026 !$context-\u003egetCustomer()) {\n $order = $orders-\u003efirst();\n\n if ($order === null) {\n throw OrderException::guestNotAuthenticated();\n }\n\n $this-\u003eguestAuthenticator-\u003evalidate($order, $request);\n}\n```\n\nFile: `src/Core/Checkout/Order/SalesChannel/OrderRoute.php`\n\nThe Store API schema also reflects that `/store-api/order` is designed for customer-owned or guest-authenticated order access, while `/store-api/handle-payment` only requires `orderId`.\n\n```json\n{\n \"summary\": \"Fetch a list of orders\",\n \"description\": \"List orders of a customer.\"\n}\n```\n\nFile: `src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json`\n\n```json\n{\n \"summary\": \"Initiate a payment for an order\",\n \"required\": [\"orderId\"]\n}\n```\n\nFile: `src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json`\n\nThe expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied `orderId` and allows a sensitive payment action on a foreign order.\n\n## Impact\n\nThe attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to `/store-api/handle-payment` in order to trigger the payment retry or payment initiation flow for another customer\u2019s order. Here, `orderId` should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid `orderId` as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.\n\n## Patch Recommendation\n\nBefore processing a supplied `orderId`, `/store-api/handle-payment` should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by `orderId`; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.",
"id": "GHSA-9v5m-39wh-5chq",
"modified": "2026-06-04T19:33:54Z",
"published": "2026-06-04T19:33:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-9v5m-39wh-5chq"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Shopware: Unauthorized Payment Trigger for Foreign Orders via /store-api/handle-payment"
}
GHSA-9VWH-R62Q-3CGR
Vulnerability from github – Published: 2025-01-15 12:30 – Updated: 2025-01-15 15:31Inappropriate implementation in Extensions in Google Chrome prior to 132.0.6834.83 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted Chrome Extension. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2025-0446"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-451"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-15T11:15:10Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Extensions in Google Chrome prior to 132.0.6834.83 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted Chrome Extension. (Chromium security severity: Low)",
"id": "GHSA-9vwh-r62q-3cgr",
"modified": "2025-01-15T15:31:24Z",
"published": "2025-01-15T12:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0446"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2025/01/stable-channel-update-for-desktop_14.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/359949844"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9W34-3VC7-7786
Vulnerability from github – Published: 2022-12-13 09:32 – Updated: 2022-12-13 09:32Multiple Wiesemann&Theis products of the ComServer Series are prone to an authentication bypass through IP spoofing. During an authenticated session to the WBM of the Com-Server an unauthenticated attacker in the same subnet can obtain the session ID and through IP spoofing change arbitrary settings by crafting modified HTTP Get requests. This may result in a complete takeover of the device.
{
"affected": [],
"aliases": [
"CVE-2022-4098"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T08:15:00Z",
"severity": "HIGH"
},
"details": "Multiple Wiesemann\u0026Theis products of the ComServer Series are prone to an authentication bypass through IP spoofing. During an authenticated session to the WBM of the Com-Server an unauthenticated attacker in the same subnet can obtain the session ID and through IP spoofing change arbitrary settings by crafting modified HTTP Get requests. This may result in a complete takeover of the device.",
"id": "GHSA-9w34-3vc7-7786",
"modified": "2022-12-13T09:32:18Z",
"published": "2022-12-13T09:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4098"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2022-057"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9WPW-58RW-F8GM
Vulnerability from github – Published: 2024-08-21 21:30 – Updated: 2024-08-22 18:31Inappropriate implementation in Views in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2024-7981"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T21:15:09Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Views in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-9wpw-58rw-f8gm",
"modified": "2024-08-22T18:31:21Z",
"published": "2024-08-21T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7981"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2024/08/stable-channel-update-for-desktop_21.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/40067456"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9WQR-9787-P4RF
Vulnerability from github – Published: 2022-07-12 00:00 – Updated: 2022-07-19 18:31In the login API, an IP address will by default be blocked when the user tries to login incorrectly more than 5 times. However, a bypass to this mechanism is possible by abusing a X-Forwarded-For header to bypass IP detection and perform a password brute-force. A patch for this issue is available in Microweber version 1.2.21.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "microweber/microweber"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-2368"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-13T15:47:17Z",
"nvd_published_at": "2022-07-11T08:15:00Z",
"severity": "MODERATE"
},
"details": "In the login API, an IP address will by default be blocked when the user tries to login incorrectly more than 5 times. However, a bypass to this mechanism is possible by abusing a X-Forwarded-For header to bypass IP detection and perform a password brute-force. A patch for this issue is available in Microweber version 1.2.21.",
"id": "GHSA-9wqr-9787-p4rf",
"modified": "2022-07-19T18:31:21Z",
"published": "2022-07-12T00:00:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2368"
},
{
"type": "WEB",
"url": "https://github.com/microweber/microweber/commit/53c000ccd5602536e28b15d9630eb8261b04a302"
},
{
"type": "PACKAGE",
"url": "https://github.com/microweber/microweber"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/a9595eda-a5e0-4717-8d64-b445ef83f452"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Microweber before 1.2.21 allows attacker to bypass IP detection to brute-force password"
}
GHSA-9WXC-6566-9FGM
Vulnerability from github – Published: 2025-10-31 18:31 – Updated: 2025-10-31 18:31Authentication bypass by spoofing in Microsoft Configuration Manager allows an authorized attacker to perform spoofing over an adjacent network.
{
"affected": [],
"aliases": [
"CVE-2025-59501"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T17:15:46Z",
"severity": "MODERATE"
},
"details": "Authentication bypass by spoofing in Microsoft Configuration Manager allows an authorized attacker to perform spoofing over an adjacent network.",
"id": "GHSA-9wxc-6566-9fgm",
"modified": "2025-10-31T18:31:14Z",
"published": "2025-10-31T18:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59501"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59501"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9X9H-W57W-JV86
Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31Authentication Bypass by Spoofing vulnerability in Pippin Williamson CGC Maintenance Mode allows Functionality Bypass.This issue affects CGC Maintenance Mode: from n/a through 1.2.
{
"affected": [],
"aliases": [
"CVE-2024-30480"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T09:15:28Z",
"severity": "LOW"
},
"details": "Authentication Bypass by Spoofing vulnerability in Pippin Williamson CGC Maintenance Mode allows Functionality Bypass.This issue affects CGC Maintenance Mode: from n/a through 1.2.",
"id": "GHSA-9x9h-w57w-jv86",
"modified": "2024-05-17T09:31:02Z",
"published": "2024-05-17T09:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30480"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/cgc-maintenance-mode/wordpress-cgc-maintenance-mode-plugin-1-2-ip-filtering-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9XP3-MP9C-47RF
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2025-11-04 21:30A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an existing pending request for the same name and forwards a new request. By default, a maximum of 150 pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name. This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the "Birthday Attacks" section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.
{
"affected": [],
"aliases": [
"CVE-2020-25686"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-358"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-20T17:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an existing pending request for the same name and forwards a new request. By default, a maximum of 150 pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name. This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the \"Birthday Attacks\" section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.",
"id": "GHSA-9xp3-mp9c-47rf",
"modified": "2025-11-04T21:30:25Z",
"published": "2022-05-24T17:39:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25686"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1890125"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QGB7HL3OWHTLEPSMLDGOMXQKG3KM2QME"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WYW3IR6APUSKOYKL5FT3ACTIHWHGQY32"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QGB7HL3OWHTLEPSMLDGOMXQKG3KM2QME"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WYW3IR6APUSKOYKL5FT3ACTIHWHGQY32"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202101-17"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/12135-security-advisory-61"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4844"
},
{
"type": "WEB",
"url": "https://www.jsof-tech.com/disclosures/dnspooq"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/434904"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.