CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
|
Description: Summary
This advisory addresses a security vulnerability in Mautic related to the segment cloning functionality. This vulnerability allows any authenticated user to clone segments without proper authorization checks.
Insecure Direct Object Reference (IDOR) / Missing Authorization: A missing authorization vulnerability exists in the cloneAction of the segment management. This allows an authenticated user to bypass intended permission restrictions and clone segments even if they lack the necessary permissions to create new ones.
Mitigation
Update Mautic to a version that implements proper authorization checks for the cloneAction within the ListController.php. Ensure that users attempting to clone segments possess the appropriate creation permissions.
Workarounds
None
If you have any questions or comments about this advisory:
Email us at [email protected]
References
https://github.com/mautic/mautic/security/advisories/GHSA-vph5-ghq3-q782
https://github.com/advisories/GHSA-vph5-ghq3-q782
May 28th, 2025 (21 days ago)
|
|
|
Description: Summary
This advisory addresses an Open Redirection vulnerability in Mautic's user unlocking endpoint. This vulnerability could be exploited by an attacker to redirect legitimate users to malicious websites, potentially leading to phishing attacks or the delivery of exploit kits.
Open Redirection via returnUrl Parameter: An Open Redirection vulnerability exists in the /s/action/unlock/user.user/0 endpoint. The returnUrl parameter, intended for post-action redirection, is not properly validated. This allows an attacker to craft a URL that, when clicked by a user, redirects them to an arbitrary external website controlled by the attacker.
Mitigation
Update Mautic to a version that properly validates or sanitizes the returnUrl parameter to ensure that redirects only occur to trusted, internal URLs or explicitly whitelisted domains.
References
https://github.com/mautic/mautic/security/advisories/GHSA-6vx9-9r2g-8373
https://github.com/advisories/GHSA-6vx9-9r2g-8373
May 28th, 2025 (21 days ago)
|
|
|
Description: Impact
This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. Due to the improper filtering of URL protocols in the repository page, an attacker can achieve cross-site scripting with permission to edit the repository.
In ui/src/app/shared/components/urls.ts, the following code exists to parse the repository URL.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/urls.ts#L14-L26
Since this code doesn't validate the protocol of repository URLs, it's possible to inject javascript: URLs here.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/repo.tsx#L5-L7
As the return value of this function is used in the href attribute of the a tag, it's possible to achieve cross-site scripting by using javascript: URLs.
Browsers may return the proper hostname for javascript: URLs, allowing exploitation of this vulnerability.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v3.0.4
v2.14.13
v2.13.8
The patch incorporates a way to validate the URL being passed in. Returning null if the validation fails.
Workarounds
There are no workarounds other than depending on the browser to filter the URL.
Credits
Disclosed by @Ry0taK RyotaK.
For more information
Open an issue in the Argo CD issue tracker or discussions
Join us o...
May 28th, 2025 (21 days ago)
|
|
|
Description: Impact
This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. Due to the improper filtering of URL protocols in the repository page, an attacker can achieve cross-site scripting with permission to edit the repository.
In ui/src/app/shared/components/urls.ts, the following code exists to parse the repository URL.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/urls.ts#L14-L26
Since this code doesn't validate the protocol of repository URLs, it's possible to inject javascript: URLs here.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/repo.tsx#L5-L7
As the return value of this function is used in the href attribute of the a tag, it's possible to achieve cross-site scripting by using javascript: URLs.
Browsers may return the proper hostname for javascript: URLs, allowing exploitation of this vulnerability.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v3.0.4
v2.14.13
v2.13.8
The patch incorporates a way to validate the URL being passed in. Returning null if the validation fails.
Workarounds
There are no workarounds other than depending on the browser to filter the URL.
Credits
Disclosed by @Ry0taK RyotaK.
For more information
Open an issue in the Argo CD issue tracker or discussions
Join us o...
May 28th, 2025 (21 days ago)
|
|
|
Description: Impact
This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. Due to the improper filtering of URL protocols in the repository page, an attacker can achieve cross-site scripting with permission to edit the repository.
In ui/src/app/shared/components/urls.ts, the following code exists to parse the repository URL.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/urls.ts#L14-L26
Since this code doesn't validate the protocol of repository URLs, it's possible to inject javascript: URLs here.
https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/repo.tsx#L5-L7
As the return value of this function is used in the href attribute of the a tag, it's possible to achieve cross-site scripting by using javascript: URLs.
Browsers may return the proper hostname for javascript: URLs, allowing exploitation of this vulnerability.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v3.0.4
v2.14.13
v2.13.8
The patch incorporates a way to validate the URL being passed in. Returning null if the validation fails.
Workarounds
There are no workarounds other than depending on the browser to filter the URL.
Credits
Disclosed by @Ry0taK RyotaK.
For more information
Open an issue in the Argo CD issue tracker or discussions
Join us o...
May 28th, 2025 (21 days ago)
|
|
|
Description: Impact
A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.
If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.
It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.
Patches
Patched version ensure proper validation of the headers and do not allow downgrading from https to http.
3.x versions are fixed on >=3.2.2
2.71.x versions are fixed on >=2.71.11
2.x versions are fixed on >=2.70.12
Workarounds
The recommended solution is to update ZITADEL to a patched version.
A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.
Questions
If you have any questions or comments about this advisory, please email us at [email protected]
Credits
Thanks to Amit Lais...
May 28th, 2025 (21 days ago)
|
|
|
Description: Impact
A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.
If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.
It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.
Patches
Patched version ensure proper validation of the headers and do not allow downgrading from https to http.
3.x versions are fixed on >=3.2.2
2.71.x versions are fixed on >=2.71.11
2.x versions are fixed on >=2.70.12
Workarounds
The recommended solution is to update ZITADEL to a patched version.
A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.
Questions
If you have any questions or comments about this advisory, please email us at [email protected]
Credits
Thanks to Amit Lais...
May 28th, 2025 (21 days ago)
|
|
Description: Decentralized finance platform Cork Protocol paused trading and launched an investigation after millions of dollars' worth of Ethereum were lost in a "security incident."
May 28th, 2025 (21 days ago)
|
|
Description: The Czech Republic on Wednesday formally accused a threat actor associated with the People's Republic of China (PRC) of targeting its Ministry of Foreign Affairs.
In a public statement, the government said it identified China as the culprit behind a malicious campaign targeting one of the unclassified networks of the Czech Ministry of Foreign Affairs. The extent of the breach is presently not
May 28th, 2025 (21 days ago)
|
|
Description: An Iranian national has pleaded guilty in the U.S. over his involvement in an international ransomware and extortion scheme involving the Robbinhood ransomware.
Sina Gholinejad (aka Sina Ghaaf), 37, and his co-conspirators are said to have breached the computer networks of various organizations in the United States and encrypted files with Robbinhood ransomware to demand Bitcoin ransom payments.
May 28th, 2025 (21 days ago)
|