Security
Headlines
HeadlinesLatestCVEs

Tag

#acer

GHSA-vq63-8f72-f486: AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass

### Description Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities: Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library `cie-aspnetcorerefers` to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML: ![](https://github.com/user-attachments/assets/5b10c8f8-5121-446f-95f8-c0355daa5959) As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the use...

ghsa
#web#js#git#acer#auth
GHSA-36h8-r92j-w9vw: The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

### Description Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities: Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library `spid-aspnetcorerefers` to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML: ![](https://github.com/user-attachments/assets/5b10c8f8-5121-446f-95f8-c0355daa5959) As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the us...

Meet the Hired Guns Who Make Sure School Cyberattacks Stay Hidden

An investigation into more than 300 cyberattacks against US K–12 schools over the past five years shows how schools can withhold crucial details from students and parents whose data was stolen.

Healthcare Sector Charts 2 More Ransomware Attacks

No ransomware groups have yet to claim responsibility for either attack, and both institutions have yet to reveal what may have been stolen.

Hackers Claim 2nd Breach at HP Enterprise, Plan to Sell Access

IntelBroker targets Hewlett-Packard Enterprise (HPE) again, claiming to have access to the company’s internal infrastructure and the possibility…

3 Use Cases for Third-Party API Security

Third-party API security requires a tailored approach for different scenarios. Learn how to adapt your security strategy to outbound data flows, inbound traffic, and SaaS-to-SaaS interconnections.

GHSA-fqmf-w4xh-33rh: gix-worktree-state nonexclusive checkout sets executable files world-writable

### Summary `gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. ### Details Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported). [`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable: - If the file is created by assuming it does not already exist, correct permissions are applied, because per...

GHSA-wphc-5f2j-jhvg: Unauthenticated DOM Based XSS in YesWiki

# Unauthenticated DOM Based XSS in YesWiki <= 4.4.5 ### Summary It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This part of the code is managed by `tools/tags/handlers/page/listpages.php`, and **[this piece of code](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/tags/handlers/page/listpages.php#L84)** is responsible for the vulnerability: ```php $output .= '<div class="alert alert-info">...

GHSA-c59p-wq67-24wx: Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify

### Summary This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. ### Details The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production. The **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the *...