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
CVE-2025-26620 |
Description: Summary
Duende.AccessTokenManagement contains a race condition when requesting access tokens using the client credentials flow. Concurrent requests to obtain an access token using differing protocol parameters can return access tokens obtained with the wrong scope, resource indicator, or other protocol parameters. Such usage is somewhat atypical, and only a small percentage of users are likely to be affected.
Details
Duende.AccessTokenManagement can request access tokens using the client credentials flow in several ways. In basic usage, the client credentials flow is configured once and the parameters do not vary. In more advanced situations, requests with varying protocol parameters may be made by calling specific overloads of these methods:
HttpContext.GetClientAccessTokenAsync()
IClientCredentialsTokenManagementService.GetAccessTokenAsync()
There are overloads of both of these methods that accept a TokenRequestParameters object that customizes token request parameters. However, concurrent requests with varying TokenRequestParameters will result in the same token for all concurrent calls.
Upgrading
Most users can simply update the NuGet package to the latest version. Customizations of the IClientCredentialsTokenCache that derive from the default implementation (DistributedClientCredentialsTokenCache) will require a small code change, as its constructor was changed to add a dependency on the ITokenRequestSynchronization service. The synchronization service will need to ...
CVSS: MEDIUM (6.3) EPSS Score: 0.05%
February 19th, 2025 (5 months ago)
|
|
Description: A Threat Actor is Allegedly Selling Access to an Unidentified Company in Belgium
February 19th, 2025 (5 months ago)
|
|
|
Description: Summary
If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It's important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it's effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force.
Details
This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute.
Impact
This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password.
Workarounds
Do not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited.
Disable the ability for users to login via an email address.
References
https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26
https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c
https://github.com/a...
February 19th, 2025 (5 months ago)
|
|
|
Description: Summary
If there are two overlapping policies for the update action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies.
E.g. have one policy allowing update access to field_a if the id == 1 and one policy allowing update access to field_b if the id == 2. The user with both these policies is allowed to update both field_a and field_b for the items with ids 1 and 2.
Details
Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item.
The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the validateItemAccess DB query, instead of only verifying access to the item as a whole. This is done by, instead of returning the actual field value, returning a flag that indicates if the user has access to that field. This uses the same case/when mechanism that is used for stripping out non permitted field that is at the core of the permissions engine.
As a result, for every item that the access is validated for, the expected result is an item that has either 1 or null for all the "requested" fields instead of any of the act...
February 19th, 2025 (5 months ago)
|
|
|
Description: Summary
If there are two overlapping policies for the update action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies.
E.g. have one policy allowing update access to field_a if the id == 1 and one policy allowing update access to field_b if the id == 2. The user with both these policies is allowed to update both field_a and field_b for the items with ids 1 and 2.
Details
Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item.
The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the validateItemAccess DB query, instead of only verifying access to the item as a whole. This is done by, instead of returning the actual field value, returning a flag that indicates if the user has access to that field. This uses the same case/when mechanism that is used for stripping out non permitted field that is at the core of the permissions engine.
As a result, for every item that the access is validated for, the expected result is an item that has either 1 or null for all the "requested" fields instead of any of the act...
February 19th, 2025 (5 months ago)
|
|
|
Description: Multiple Russia-aligned threat actors have been observed targeting individuals of interest via the privacy-focused messaging app Signal to gain unauthorized access to their accounts.
"The most novel and widely used technique underpinning Russian-aligned attempts to compromise Signal accounts is the abuse of the app's legitimate 'linked devices' feature that enables Signal to be used on multiple
February 19th, 2025 (5 months ago)
|
|
|
Description: Genea, one of Australia's largest fertility services providers, disclosed that unknown attackers breached its network and accessed data stored on compromised systems. [...]
February 19th, 2025 (5 months ago)
|
|
|
Description: The FakeUpdate malware campaigns are increasingly becoming muddled, with two additional cybercrime groups tracked as TA2726 and TA2727, running campaigns that push a new macOS infostealer malware called FrigidStealer. [...]
February 19th, 2025 (5 months ago)
|
|
|
Description: EDRVendor Claims to be Selling Italian Police Government Email Access with Five Law Enforcement Panels
February 19th, 2025 (5 months ago)
|
|
|
Description: Idriss Qibaa, a “professional when it comes to the banning and unbanning of Instagram accounts" who ran “Unlocked 4 Life,” claimed he made more than $600,000 a month.
February 19th, 2025 (5 months ago)
|