Insufficient capability checks made it possible to disable badges a user does not have permission to access.

Skip to content

**Navigation Menu**

*   *   GitHub Copilot
        
        Write better code with AI
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Actions
        
        Automate any workflow
        
    *   Codespaces
        
        Instant dev environments
        
    *   Issues
        
        Plan and track work
        
    *   Code Review
        
        Manage code changes
        
    *   Discussions
        
        Collaborate outside of code
        
    *   Code Search
        
        Find more, search less
        
    

*   Explore
    
    *   Learning Pathways
    *   Events & Webinars
    *   Ebooks & Whitepapers
    *   Customer Stories
    *   Partners
    *   Executive Insights
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   *   Enterprise platform
        
        AI-powered developer platform
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-26531

**Moodle has an IDOR in badges allows disabling of arbitrary badges**

Low severity GitHub Reviewed Published Feb 24, 2025 to the GitHub Advisory Database • Updated Feb 24, 2025

**Package**

composer moodle/moodle (Composer)

**Affected versions**

\>= 4.5.0-beta, < 4.5.2

\>= 4.4.0-beta, < 4.4.6

\>= 4.3.0-beta, < 4.3.10

< 4.1.16

**Patched versions**

4.5.2

4.4.6

4.3.10

4.1.16

**Description**

Published to the GitHub Advisory Database

Feb 24, 2025

Last updated

Feb 24, 2025

**EPSS score**

GHSA-g88w-v4cq-qgcp: Moodle has an IDOR in badges allows disabling of arbitrary badges

Tags not expected to be visible to a user could still be discovered by them via the tag search page or in the tags block.

Skip to content

**Navigation Menu**

*   *   GitHub Copilot
        
        Write better code with AI
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Actions
        
        Automate any workflow
        
    *   Codespaces
        
        Instant dev environments
        
    *   Issues
        
        Plan and track work
        
    *   Code Review
        
        Manage code changes
        
    *   Discussions
        
        Collaborate outside of code
        
    *   Code Search
        
        Find more, search less
        
    

*   Explore
    
    *   Learning Pathways
    *   Events & Webinars
    *   Ebooks & Whitepapers
    *   Customer Stories
    *   Partners
    *   Executive Insights
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   *   Enterprise platform
        
        AI-powered developer platform
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-26527

**Moodle's non-searchable tags can still be discovered on the tag search page and in the tags block**

Moderate severity GitHub Reviewed Published Feb 24, 2025 to the GitHub Advisory Database • Updated Feb 24, 2025

**Package**

composer moodle/moodle (Composer)

**Affected versions**

\>= 4.5.0-beta, < 4.5.2

\>= 4.4.0-beta, < 4.4.6

\>= 4.3.0-beta, < 4.3.10

< 4.1.16

**Patched versions**

4.5.2

4.4.6

4.3.10

4.1.16

**Description**

Published to the GitHub Advisory Database

Feb 24, 2025

Last updated

Feb 24, 2025

**EPSS score**

GHSA-5r85-6h7f-rg3r: Moodle's non-searchable tags can still be discovered on the tag search page and in the tags block

Additional checks were required to ensure trusttext is applied (when enabled) to glossary entries being restored.

Skip to content

**Navigation Menu**

*   *   GitHub Copilot
        
        Write better code with AI
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Actions
        
        Automate any workflow
        
    *   Codespaces
        
        Instant dev environments
        
    *   Issues
        
        Plan and track work
        
    *   Code Review
        
        Manage code changes
        
    *   Discussions
        
        Collaborate outside of code
        
    *   Code Search
        
        Find more, search less
        
    

*   Explore
    
    *   Learning Pathways
    *   Events & Webinars
    *   Ebooks & Whitepapers
    *   Customer Stories
    *   Partners
    *   Executive Insights
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   *   Enterprise platform
        
        AI-powered developer platform
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-26532

**Moodle allows teachers to evade trusttext config when restoring glossary entries**

Low severity GitHub Reviewed Published Feb 24, 2025 to the GitHub Advisory Database • Updated Feb 24, 2025

**Package**

composer moodle/moodle (Composer)

**Affected versions**

\>= 4.5.0-beta, < 4.5.2

\>= 4.4.0-beta, < 4.4.6

\>= 4.3.0-beta, < 4.3.10

< 4.1.16

**Patched versions**

4.5.2

4.4.6

4.3.10

4.1.16

**Description**

Published to the GitHub Advisory Database

Feb 24, 2025

Last updated

Feb 24, 2025

**EPSS score**

GHSA-cw24-f6fq-7j9v: Moodle allows teachers to evade trusttext config when restoring glossary entries

The drag-and-drop onto image (ddimageortext) question type required additional sanitizing to prevent a stored XSS risk.

Skip to content

**Navigation Menu**

*   *   GitHub Copilot
        
        Write better code with AI
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Actions
        
        Automate any workflow
        
    *   Codespaces
        
        Instant dev environments
        
    *   Issues
        
        Plan and track work
        
    *   Code Review
        
        Manage code changes
        
    *   Discussions
        
        Collaborate outside of code
        
    *   Code Search
        
        Find more, search less
        
    

*   Explore
    
    *   Learning Pathways
    *   Events & Webinars
    *   Ebooks & Whitepapers
    *   Customer Stories
    *   Partners
    *   Executive Insights
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   *   Enterprise platform
        
        AI-powered developer platform
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-26528

**Moodle has a stored XSS in ddimageortext question type**

Low severity GitHub Reviewed Published Feb 24, 2025 to the GitHub Advisory Database • Updated Feb 24, 2025

**Package**

composer moodle/moodle (Composer)

**Affected versions**

\>= 4.5.0-beta, < 4.5.2

\>= 4.4.0-beta, < 4.4.6

\>= 4.3.0-beta, < 4.3.10

< 4.1.16

**Patched versions**

4.5.2

4.4.6

4.3.10

4.1.16

**Description**

Published to the GitHub Advisory Database

Feb 24, 2025

Last updated

Feb 24, 2025

**EPSS score**

GHSA-h697-w4ph-7pcx: Moodle has a stored XSS in ddimageortext question type

An SQL injection risk was identified in the module list filter within course search.

Skip to content

**Navigation Menu**

*   *   GitHub Copilot
        
        Write better code with AI
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Actions
        
        Automate any workflow
        
    *   Codespaces
        
        Instant dev environments
        
    *   Issues
        
        Plan and track work
        
    *   Code Review
        
        Manage code changes
        
    *   Discussions
        
        Collaborate outside of code
        
    *   Code Search
        
        Find more, search less
        
    

*   Explore
    
    *   Learning Pathways
    *   Events & Webinars
    *   Ebooks & Whitepapers
    *   Customer Stories
    *   Partners
    *   Executive Insights
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   *   Enterprise platform
        
        AI-powered developer platform
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-26533

**Moodle has a SQL injection risk in course search module list filter**

High severity GitHub Reviewed Published Feb 24, 2025 to the GitHub Advisory Database • Updated Feb 24, 2025

**Package**

composer moodle/moodle (Composer)

**Affected versions**

\>= 4.5.0-beta, < 4.5.2

\>= 4.4.0-beta, < 4.4.6

\>= 4.3.0-beta, < 4.3.10

< 4.1.16

**Patched versions**

4.5.2

4.4.6

4.3.10

4.1.16

**Description**

Published to the GitHub Advisory Database

Feb 24, 2025

Last updated

Feb 24, 2025

**EPSS score**

GHSA-rg56-94j7-hjx9: Moodle has a SQL injection risk in course search module list filter

Description information displayed in the site administration live log required additional sanitizing to prevent a stored XSS risk.

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity: More severe for the least complex attacks.

Privileges required: More severe if no privileges are required.

User interaction: More severe when no user interaction is required.

Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability: More severe when the loss of impacted component availability is highest.

GHSA-wr88-x8cm-7cgq: Moodle has a stored XSS risk in admin live log

The question bank filter required additional sanitizing to prevent a reflected XSS risk.

GHSA-4w32-c9g7-27qx: Moodle allows reflected XSS via question bank filter

### Summary
A bypass was found for the security feature **trustedOrigins**. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a **Open Redirect** vulnerability, where it can be used to steal the **reset password token** of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker.

### Details

#### Absolute URLs

The issue here appears in the **middleware**,  [specifically](https://github.com/better-auth/better-auth/blob/ddebd0358d74376ea64541512d0167dd4377f182/packages/better-auth/src/api/middlewares/origin-check.ts#L53). This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload `/\/example.com`. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:

![image](https://github.com/user-attachments/assets/d192f06d-358d-4612-97d9-cab89ba55b06)

```typescript
// trustedOrigins = [ "https://example.com" ]
validateURL("https://attacker.com", "callbackURL") // ❌ APIError, No Redirect
validateURL("/\/attacker.com", "callbackURL")       // ✅ Redirect to http://attacker.com
```

#### Regex

The issue here is because the regex is not strong enough `[^/\\]*?\.example\.com[/\\]*?` ( this is the regex it will be created if we have a wildcard as config ), but we can bypass by using a payload like:

```text
// trustedOrigins = [ "*.example.com" ]
  ┌──────────────────┐       ┌────────────────┐       ┌─────────────────┐
  │ None of [ "/\" ] │ ────▶ │ ".example.com" │ ────▶ │ One of [ "/\" ] │
  └──────────────────┘       └────────────────┘       └─────────────────┘
          demo                  .example.com                    /               ✅ Redirect to https://example.com
          demo                  .attacker.com                   /               ❌ APIError, no redirect
   http:attacker.com?           .example.com                    /               ✅ Redirect to http://attacker.com
````

This works because **:** and **?** are special chars in a URL, so when the URL parser sees, **http:** it will fix our happily fix our URL to http://attacker.com? and make  `.example.com` as parameter, thus, bypassing this check

### PoC
We can PoC the open redirect by using the `demo.better-auth.com`. 
If we access the URL bellow, we are redirected to example.com:
- https://demo.better-auth.com/api/auth/reset-password/x?callbackURL=/\/example.com

### Impact
Every single website using the **better-auth** library, is vulnerable to un-auth open redirect and more importantilly, vulnerable to potential one click account take over vulnerability, as the attacker can send the victim a email to reset their account while changing the "redirectTo" parameter [here](https://demo.better-auth.com/forget-password), and when the victim clicks on the link, the reset token is sent to the attackers website, thus making the attacker to use the token stolen and reset the password of the victim.

**Summary**

A bypass was found for the security feature **trustedOrigins**. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a **Open Redirect** vulnerability, where it can be used to steal the **reset password token** of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker.

**Details****Absolute URLs**

The issue here appears in the **middleware**, specifically. This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload /\/example.com. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:

// trustedOrigins = \[ "https://example.com" \]
validateURL("https://attacker.com", "callbackURL") // ❌ APIError, No Redirect
validateURL("/\\/attacker.com", "callbackURL")       // ✅ Redirect to http://attacker.com

**Regex**

The issue here is because the regex is not strong enough [^/\\]*?\.example\.com[/\\]*? ( this is the regex it will be created if we have a wildcard as config ), but we can bypass by using a payload like:

    // trustedOrigins = [ "*.example.com" ]
      ┌──────────────────┐       ┌────────────────┐       ┌─────────────────┐
      │ None of [ "/\" ] │ ────▶ │ ".example.com" │ ────▶ │ One of [ "/\" ] │
      └──────────────────┘       └────────────────┘       └─────────────────┘
              demo                  .example.com                    /               ✅ Redirect to https://example.com
              demo                  .attacker.com                   /               ❌ APIError, no redirect
       http:attacker.com?           .example.com                    /               ✅ Redirect to http://attacker.com
    

This works because **:** and **?** are special chars in a URL, so when the URL parser sees, **http:** it will fix our happily fix our URL to http://attacker.com? and make .example.com as parameter, thus, bypassing this check

**PoC**

We can PoC the open redirect by using the demo.better-auth.com.  
If we access the URL bellow, we are redirected to example.com:

*   https://demo.better-auth.com/api/auth/reset-password/x?callbackURL=/\\/example.com

**Impact**

Every single website using the **better-auth** library, is vulnerable to un-auth open redirect and more importantilly, vulnerable to potential one click account take over vulnerability, as the attacker can send the victim a email to reset their account while changing the "redirectTo" parameter here, and when the victim clicks on the link, the reset token is sent to the attackers website, thus making the attacker to use the token stolen and reset the password of the victim.

**References**

*   GHSA-vp58-j275-797x
*   better-auth/better-auth@b381cac
*   https://github.com/better-auth/better-auth/blob/ddebd0358d74376ea64541512d0167dd4377f182/packages/better-auth/src/api/middlewares/origin-check.ts#L53

GHSA-vp58-j275-797x: Better Auth allows bypassing the trustedOrigins Protection which leads to ATO

A botnet of 130,000 devices is launching a Password-Spraying attack on Microsoft 365, bypassing MFA and exploiting legacy authentication to access accounts.

A new botnet-powered cyber attack is putting Microsoft 365 users at risk. Security researchers at SecurityScorecard have reported that over 130,000 compromised devices are being used to launch coordinated password-spraying attacks against Microsoft 365 accounts.

****What’s Happening?****

Instead of relying on the usual login mechanisms that trigger alerts through repeated failed attempts, the attackers are using non-interactive sign-ins for their campaigns. This method is normally meant for automated processes or background services and does not invoke the usual MFA checks. As a result, suspicious activities may go unnoticed by security monitoring systems that focus on standard user log-ins.

What’s more, attackers are making systematic attempts using stolen credentials from infostealer logs. Their approach targets a wide range of Microsoft 365 tenants, affecting organizations from financial services, healthcare, government, technology firms, and educational institutions.

****How the Attack Works****

*   **Non-Interactive Sign-Ins:** The attackers perform sign-in attempts that do not trigger immediate account lockouts or alerts. Since these log-ins are not interactive, they often escape the notice of standard monitoring tools.

*   **Basic Authentication Abuse:** By exploiting legacy Basic Authentication protocols, attackers send user credentials without encryption. This leaves accounts more exposed compared to modern authentication methods.

*   **Command and Control Coordination:** Evidence shows that attackers are coordinating their efforts through six command-and-control (C2) servers. These servers communicate with thousands of infected devices and are supported by proxy services from well-known cloud providers with ties to China. Analysis of the network traffic has revealed several open ports on these servers, which are likely used for tasks such as managing the botnet and sending instructions to the compromised devices.

According to SecurityScorecard’s report, this is concerning for organizations relying on Microsoft 365, as they face multiple risks. Unauthorized account access can expose sensitive emails, documents, and collaboration tools to attackers. Service disruptions may occur due to repeated login attempts, leading to account lockouts that interrupt daily operations.

Additionally, once in control, cybercriminals can misuse compromised accounts for phishing campaigns or move laterally within the organization, further escalating security threats. Because the attack exploits non-interactive sign-ins, teams that monitor just the usual interactive log-in events might miss these suspicious activities. Updating security monitoring to include non-interactive log events is an important step for organizations using Microsoft 365.

Security teams are encouraged to review sign-in logs carefully. Paying attention to non-interactive log entries and suspicious login attempts can help spot this kind of unwanted activity.

Organizations should audit background service accounts by identifying those using Basic Authentication and updating any exposed credentials found in non-interactive sign-in logs. It’s also crucial to review authentication methods and transition from legacy protocols to modern authentication practices that fully support MFA.

Additionally, monitoring for unusual traffic, such as abnormal login patterns or connections from IP addresses associated with command and control servers, can help detect and mitigate potential security threats.

With Microsoft planning to fully retire certain Basic Authentication protocols later this year, now is a good time for organizations to strengthen their protection against these kinds of covert attacks.

Jason Soroko, Senior Fellow at Sectigo, a Scottsdale, Arizona-based provider of comprehensive certificate lifecycle management (CLM), offers valuable insights into securing non-interactive logins in Microsoft 365.

“Non-interactive logins are widespread in Microsoft 365, driven by service accounts, automated tasks, and API integrations,” Soroko explains. “They often represent a significant portion of overall authentication events, as background processes routinely access resources without direct user input.”

Unlike interactive user authentication, Multi-Factor Authentication (MFA) isn’t typically applicable to non-interactive logins. “Instead, these automated logins should use alternative secure mechanisms such as certificates, or other forms of non-shared managed identities,” Soroko advises. “Organizations should better secure non-interactive access with conditional access policies, strict credential management, and continuous monitoring.”

Microsoft 365 offers configurations to restrict non-interactive logins. “Administrators can enforce stronger authentication via conditional access policies and block legacy protocols that facilitate these silent sign-ins,” Soroko notes. “However, such restrictions must be applied thoughtfully to avoid disrupting legitimate automated processes.”

Botnet of 130K Devices Targets Microsoft 365 in Password-Spraying Attack

The http parser in Phusion Passenger 6.0.21 through 6.0.25 before 6.0.26 allows a denial of service during parsing of a request with an invalid HTTP method.

Latest News