DerbyNet version 9.0 suffers from a cross site scripting vulnerability in photo-thumbs.php.

CVE ID: CVE-2024-30925

Description:  
A Cross-Site Scripting (XSS) vulnerability exists in DerbyNet version 9.0, specifically within the `photo-thumbs.php` component. This issue enables a remote attacker to execute arbitrary code through the improper handling of the `racerid` and `back` parameters. The vulnerability arises because the application dynamically generates URLs for navigation without adequately sanitizing these parameters, thus allowing the injection of malicious scripts.

Vulnerability Type: Cross-Site Scripting (XSS)

Vendor of Product: DerbyNet - Available on GitHub: https://github.com/jeffpiazza/derbynet

Affected Product Code Base: DerbyNet - v9.0

Affected Component: photo-thumbs.php

Attack Type: Remote

Impact: Code execution

Attack Vectors:  
The XSS vulnerability can be exploited through manipulation of the `racerid` and `back` parameters in the URL. Examples of such manipulation include:  
- http://127.0.0.1:8000/photo-thumbs.php?repo=head&racerid=</script><script>alert(1)</script>  
- http://127.0.0.1:8000/photo-thumbs.php?back="><script>alert(1)</script></div>

These URLs demonstrate how an attacker could inject and execute arbitrary JavaScript within the context of the user's browser session.

Discoverer: Valentin Lobstein

References:  
- Official website: http://derbynet.com  
- Source code on GitHub: https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 photo-thumbs.php Cross Site Scripting

DerbyNet version 9.0 suffers from a cross site scripting vulnerability in checkin.php.

CVE ID: CVE-2024-30924

Description:  
A Cross Site Scripting (XSS) vulnerability has been identified in DerbyNet version 9.0, specifically within the `checkin.php` component. This vulnerability allows remote attackers to execute arbitrary code due to improper handling of the `order` URL parameter. The flaw lies in the way the `order` parameter is embedded directly into a JavaScript variable assignment without adequate sanitization or encoding, making it possible to inject scripts.

Vulnerability Type: Cross Site Scripting (XSS)

Vendor of Product: DerbyNet - Available on GitHub: https://github.com/jeffpiazza/derbynet

Affected Product Code Base: DerbyNet - v9.0

Affected Component: checkin.php

Attack Type: Remote

Impact: Code execution is possible as a result of this vulnerability.

Attack Vectors:  
The XSS vulnerability can be exploited by manipulating the `order` parameter in the URL. For example:  
- `http://127.0.0.1:8000/checkin.php?order=</script><script>alert(1)</script>`  
- `http://127.0.0.1:8000/checkin.php?order=';alert(1);//`

These attack vectors demonstrate how an attacker could inject and execute arbitrary JavaScript within the context of the user's browser session.

Discoverer: Valentin Lobstein

References:  
- Official website: http://derbynet.com  
- Source code on GitHub: https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 checkin.php Cross Site Scripting

DerbyNet version 9.0 suffers from a cross site scripting vulnerability in photo.php.

    CVE ID: CVE-2024-30921Description:A Cross-Site Scripting (XSS) vulnerability has been identified in DerbyNet version 9.0, specifically affecting the photo.php component. This vulnerability allows remote attackers to execute arbitrary code via crafted URLs, without requiring authentication.Vulnerability Type: Cross-Site Scripting (XSS)Vendor of Product: DerbyNet - Available on GitHub: https://github.com/jeffpiazza/derbynetAffected Product Code Base: DerbyNet - v9.0Affected Component: photo.phpAttack Type: RemoteImpact: Code executionAttack Vectors: The vulnerability can be exploited by navigating to a specially crafted URL such as:- http://127.0.0.1:8000/photo.php/<img src=x onerror=alert(1)>This method allows the attacker to inject arbitrary JavaScript that will be executed in the context of the victim's browser.Discoverer: Valentin LobsteinReferences:- Official website: http://derbynet.com- Source code on GitHub: https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 photo.php Cross Site Scripting

DerbyNet version 9.0 suffers from a cross site scripting vulnerability in render-document.php.

    CVE ID: CVE-2024-30920Description:A Cross Site Scripting (XSS) vulnerability has been identified in DerbyNet v9.0, specifically within the `render-document.php` component. This vulnerability allows a remote attacker to execute arbitrary code via crafted URLs. The root cause of the vulnerability is the application's failure to properly sanitize user input in document rendering paths, which permits the injection of malicious scripts.Vulnerability Type: XSS (Cross Site Scripting)Vendor of Product:DerbyNet - https://github.com/jeffpiazza/derbynetAffected Product Code Base:DerbyNet - v9.0Affected Component:render-document.phpAttack Type:RemoteImpact:Code executionRoot Cause:The vulnerability arises from the application's display of debug information, including `ORIG_SCRIPT_FILENAME`, `DOCUMENT_URI`, `SCRIPT_NAME`, and `PHP_SELF`. These debug outputs improperly handle user-supplied input by not sanitizing it before inclusion in the output, leading directly to XSS vulnerabilities when malicious inputs are rendered by the browser.Attack Vectors:The vulnerability can be exploited with URLs such as:- `http://127.0.0.1:8000/render-document.php/racer/<img src=x onerror=alert(1)>`- `http://127.0.0.1:8000/render-document.php/<img src=x onerror=alert(1)>`Discoverer:Valentin LobsteinReferences:- http://derbynet.com- https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 render-document.php Cross Site Scripting

Seo Panel version 4.7.0 suffers from a cross site scripting vulnerability.

    # Exploit Title: Seo Panel 4.7.0 Reflected XSS# Exploit Author: Arzu DEMÝREZ# Date: 05.03-2024# Vendor Homepage: https://www.seopanel.org/# Software Link:  https://github.com/seopanel/Seo-Panel/releases/tag/4.7.0# Version: Seo Panel 4.7.0-Description: A cross-site scripting (XSS) issue in the SEO admin login panel version 4.7.0 allows remote attackers to inject JavaScript.- used:x" onmouseover=alert(document.cookie) x="Review Of Analysis:Ýn archive.ctp.php file include search_form and search_name input load on that script at line 71 as<a href="javascript:void(0);" onclick="scriptDoLoadPost('archive.php', 'search_form', 'content')" class="actionbut"><?php echo $spText['button']['Search']?></a>because of that an attacker if send that codex" onmouseover=alert(document.cookie) x="can exploit the victim.<form id='search_form'>    <table width="100%" class="search">        <tr>            <th><?php echo $spText['common']['Name']?>: </th>            <td>                <input type="text" name="search_name" value="<?php echo htmlentities($searchInfo['search_name'], ENT_QUOTES)?>" onblur="<?php echo $submitLink?>">            </td>            <th><?php echo $spText['common']['Period']?>:</th>            <td colspan="2">                <input type="text" value="<?php echo $fromTime?>" name="from_time" id="from_time_summary"/>                <input type="text" value="<?php echo $toTime?>" name="to_time" id="to_time_summary"/>                <script>                  $( function() {                    $( "#from_time_summary, #to_time_summary").datepicker({dateFormat: "yy-mm-dd"});                  } );                </script>            </td>        <tr>        <tr>            <th><?php echo $spText['common']['Website']?>: </th>            <td>                <select name="website_id" id="website_id"  onchange="scriptDoLoadPost('archive.php', 'search_form', 'content')" style="width: 180px;">                    <option value="">-- <?php echo $spText['common']['Select']?> --</option>                    <?php foreach($siteList as $websiteInfo){?>                        <?php if($websiteInfo['id'] == $websiteId){?>                            <option value="<?php echo $websiteInfo['id']?>" selected><?php echo $websiteInfo['name']?></option>                        <?php }else{?>                            <option value="<?php echo $websiteInfo['id']?>"><?php echo $websiteInfo['name']?></option>                        <?php }?>                    <?php }?>                </select>            </td>            <th><?php echo $spText['label']['Report Type']?>: </th>            <td>                <select name="report_type" id="report_type" onchange="scriptDoLoadPost('archive.php', 'search_form', 'content')" style="width: 210px;">                    <option value="">-- <?php echo $spText['common']['Select']?> --</option>                    <?php foreach($reportTypes as $type => $info){?>                        <?php if($type == $searchInfo['report_type']){?>                            <option value="<?php echo $type?>" selected><?php echo $info?></option>                        <?php }else{?>                            <option value="<?php echo $type?>"><?php echo $info?></option>                        <?php }?>                    <?php }?>                </select>                <a href="javascript:void(0);" onclick="scriptDoLoadPost('archive.php', 'search_form', 'content')" class="actionbut"><?php echo $spText['button']['Search']?></a>Saygýlarýmla / Best Regards,[cid:e33e203c-58cd-46ba-b1ea-f27e999dc68d]

Seo Panel 4.7.0 Cross Site Scripting

Large language models require rethinking how to bake security into the software development process earlier.

Large language models require rethinking how to bake security into the software development process earlier.

Source: Chroma Craft Media Group via Alamy Stock Photo

Question: What do we really know about large language model (LLM) security? And are we willingly opening the front door to chaos by using LLMs in business?

Rob Gurzeev, CEO, CyCognito: Picture it: Your engineering team is harnessing the immense capabilities of LLMs to "write code" and rapidly develop an application. It's a game-changer for your businesses; development speeds are now orders of magnitude faster. You've shaved 30% off time-to-market. It's win-win — for your org, your stakeholders, your end users.

Six months later, your application is reported to leak customer data; it has been jailbroken and its code manipulated. You're now facing SEC violations and the threat of customers walking away.

Efficiency gains are enticing, but the risks cannot be ignored. While we have well-established standards for security in traditional software development, LLMs are black boxes that require rethinking how we bake in security.

**New Kinds of Security Risks for LLMs**

LLMs are rife with unknown risks and prone to attacks previously unseen in traditional software development.

*   Prompt injection attacks involve manipulating the model to generate unintended or harmful responses. Here, the attacker strategically formulates prompts to deceive the LLM, potentially bypassing security measures or ethical constraints put in place to ensure responsible use of the artificial intelligence (AI). As a result, the LLM's responses can deviate significantly from the intended or expected behavior, posing serious risks to privacy, security, and the reliability of AI-driven applications.
    
*   Insecure output handling arises when the output generated by an LLM or similar AI system is accepted and incorporated into a software application or Web service without undergoing adequate scrutiny or validation. This can expose back-end systems to vulnerabilities, such as cross-site scripting (XSS), cross-site request forgery (CSRF), server-side request forgery (SSRF), privilege escalation, and remote code execution (RCE).
    
*   Training data poisoning occurs when the data used to train an LLM is deliberately manipulated or contaminated with malicious or biased information. The process of training data poisoning typically involves the injection of deceptive, misleading, or harmful data points into the training dataset. These manipulated data instances are strategically chosen to exploit vulnerabilities in the model's learning algorithms or to instill biases that may lead to undesired outcomes in the model's predictions and responses.
    

**A Blueprint for Protection and Control of LLM Applications**

While some of this is new territory, there are best practices you can implement to limit exposure.

*   Input sanitization involves, as the name suggestion, the sanitization of inputs to prevent unauthorized actions and data requests initiated by malicious prompts. The first step is input validation to ensure input adheres to expected formats and data types. The next is input sanitization, where potentially harmful characters or code are removed or encoded to thwart attacks. Other tactics include whitelists of approved content, blacklists of forbidden content, parameterized queries for database interactions, content security policies, regular expressions, logging, and continuous monitoring, as well as security updates and testing.
    
*   Output scrutiny is the rigorous handling and evaluation of the output generated by the LLM to mitigate vulnerabilities, like XSS, CSRF, and RCE. The process begins by validating and filtering the LLM's responses before accepting them for presentation or further processing. It incorporates techniques such as content validation, output encoding, and output escaping, all of which aim to identify and neutralize potential security risks in the generated content.
    
*   Safeguarding training data is essential to prevent training data poisoning. This involves enforcing strict access controls, employing encryption for data protection, maintaining data backups and version control, implementing data validation and anonymization, establishing comprehensive logging and monitoring, conducting regular audits, and providing employee training on data security. It's also important to verify the reliability of data sources and ensure secure storage and transmission practices.
    
*   Enforcing strict sandboxing policies and access controls can also help mitigate the risk of SSRF exploits in LLM operations. Techniques that can be applied here include sandbox isolation, access controls, whitelisting and/or blacklisting, request validation, network segmentation, content-type validation, and content inspection. Regular updates, comprehensive logging, and employee training are also key.
    
*   Continuous monitoring and content filtering can be integrated into the LLM's processing pipeline to detect and prevent harmful or inappropriate content, using keyword-based filtering, contextual analysis, machine-learning models, and customizable filters. Ethical guidelines and human moderation play key roles in maintaining responsible content generation, while continuous real-time monitoring, user feedback loops, and transparency ensure that any deviations from desired behavior are promptly addressed.
    

**About the Author(s)**

Dark Reading

The Edge is Dark Reading's home for features, threat data and in-depth perspectives on cybersecurity.

You May Also Like

How Do We Integrate LLMs Security Into Application Development?

Nearly three months after Operation Cronos, it's clear the gang is not bouncing back from the innovative law-enforcement action. RaaS operators are on notice, and businesses should pay attention.

Source: Jan Zwoliński via Alamy Stock Photo

Despite the LockBit ransomware-as-a-service (RaaS) gang claiming to be back after a high-profile takedown in mid-February, an analysis reveals significant, ongoing disruption to the group's activities — along with ripple effects throughout the cybercrime underground, with implications for business risk.

LockBit was responsible for 25% to 33% of all ransomware attacks in 2023, according to Trend Micro, easily making it the biggest financial threat actor group of the last year. Since it emerged in 2020, it has claimed thousands of victims and millions in ransom, including cynical hits on hospitals during the pandemic.

The Operation Cronos effort, involving multiple law enforcement agencies around the world, led to outages on LockBit-affiliated platforms, and a takeover of its leak site by the UK's National Crime Agency (NCA). Authorities then used the latter to make arrests, impose sanctions, seize cryptocurrency, and more activities related to the inner workings of the group. They also publicized the LockBit admin panel and exposed the names of affiliates working with the group.

Further, they noted that decryption keys would be made available, and revealed that LockBit, contrary to its promises to victims, never deleted victim data after payments were made.

In all it was a savvy show of force and access from the policing community, spooking others in the ecosystem in the immediate aftermath and leading to wariness when it comes to working with any re-emergent version of LockBit and its ringleader, who goes by the handle "LockBitSupp."

Researchers from Trend Micro noted that, two and a half months after Operation Cronos, there's precious little evidence that things are turning around for the group — despite LockBitSupp's claims that the group is clawing its way back into normal operations.

**A Different Kind of Cybercrime Takedown**

Operation Cronos was initially met with skepticism by researchers, who pointed out that other recent, high-profile takedowns of RaaS groups like Black Basta, Conti, Hive, and Royal (not to mention the infrastructure for initial access trojans like Emotet, Qakbot, and TrickBot), have resulted in only temporary setbacks for their operators.

However, the LockBit strike is different: The sheer amount of information that law enforcement was able to access and make public has permanently damaged the group's standing in Dark Web circles.

"While they often focus on taking out command and control infrastructure, this effort went further," Trend Micro researchers explained in an analysis released today. "It saw police manage to compromise LockBit's admin panel, expose affiliates, and access information and conversations between affiliates and victims. This cumulative effort has helped to tarnish the reputation of LockBit among affiliates and the cybercrime community in general, which will make it harder to come back from."

Indeed, the fallout from the cybercrime community was swift, Trend Micro observed. For one, LockBitSupp has been banned from two popular underground forums, XSS and Exploit, hampering the admin's ability to garner support and rebuild.

Shortly after, a user on X (formerly Twitter) called "Loxbit" meanwhile claimed in a public post to have been cheated by LockBitSupp, while another presumed affiliate called "michon" opened up a forum arbitration thread against LockBitSupp for nonpayment. One initial-access broker using the handle "dealfixer" advertised its wares but specifically mentioned that they did not want to work with anybody from LockBit. And another IAB, "n30n," opened a claim on the ramp\_v2 forum about loss of payment surrounding the disruption.

Perhaps worse, some forum commentators were extremely concerned by the sheer amount of information that police were able to compile, and some speculated that LockBitSupp may even have worked with law enforcement on the operation. LockBitSupp quickly announced that a vulnerability in PHP was to blame for the ability of law enforcement to infiltrate the gang's information; Dark Web denizens simply pointed out that the bug is months old and criticized LockBit's security practices and lack of protection for affiliates.

"The sentiments of the cybercrime community to LockBit's disruption ranged from satisfaction to speculation about the group's future, hinting at the significant impact of the incident on the RaaS industry," according to Trend Micro's analysis, released today.

**LockBit Disruption's Chilling Effect on the RaaS Industry**

Indeed, the disruption has sparked some self-reflection among other active RaaS groups: A Snatch RaaS operator pointed out on its Telegram channel that they were all at risk.

"Disrupting and undermining the business model seem to have had a far more cumulative effect than executing a technical takedown," according to Trend Micro. "Reputation and trust are key to attracting affiliates, and when these are lost, it's harder to get people to return. Operation Cronos succeeded in striking against one element of its business that was most important: its brand."

Jon Clay, Trend Micro's vice president of threat intelligence, tells Dark Reading that LockBit's defanging and the disruption's chilling effect on RaaS groups in general present an opportunity for business risk management.

"This can be a time for businesses to reassess their defense models as we may see a slowdown in attacks while these other groups assess their own operational security," he notes. "This is also a time to review a business incident response plan to make sure you have all aspects of a breach covered, including business operation continuity, cyber insurance, and the response — to pay or not pay."

**LockBit Signs of Life Are Greatly Exaggerated**

LockBitSupp is nonetheless attempting to bounce back, Trend Micro found — though with few positive results.

New Tor leak sites launched a week after the operation, and LockBitSupp said on ramp\_v2 forum that the gang is actively seeking out IABs with access to .gov, .edu, and .org domains, indicating a thirst for revenge. It wasn't long before scores of supposed victims started appearing on the leak site, starting with the FBI.

However, when the ransom payment deadline came and went, instead of sensitive FBI data appearing on the site, LockBitSupp posted a lengthy declaration that it would continue to operate. In addition, more than two-thirds of the victims consisted of reuploaded attacks that occurred prior to Operation Cronos. Of the others, the victims belonged to other groups, such as ALPHV. In all, Trend Micro's telemetry revealed just one small true LockBit activity cluster after Cronos, from an affiliate in southeast Asia that carried a low, $2,800 ransom demand.

Perhaps more concerningly, the group has also been developing a new version of ransomware — Lockbit-NG-Dev. Trend Micro found it to have a new .NET core, which allows it to be more platform-agnostic; it also removes self-propagating capabilities and the ability to print ransom notes via the user's printers.

"The code base is completely new in relation to the move to this new language, which means that new security patterns will likely be needed to detect it. It's still a functional and powerful piece of ransomware," researchers warned.

Still, these are anemic sign of life at best for LockBit, and Clay notes that its unclear where it or its affiliates may go next. In general, he warns, defenders will need to be prepared for shifts in ransomware gang tactics going forward as those participating in the ecosystem assess the state of play.

"RaaS groups are likely looking at their own weaknesses being caught by law enforcement," he explains. "They may review what types of businesses/organizations they target so as to not give much attention to their attacks. Affiliates may look at how they can rapidly shift from one group to another in case their main RaaS group gets taken down."

He adds, "shifting towards data exfiltration only versus ransomware deployments may increase as these don't disrupt a business, but can still allow profits. We could also see RaaS groups shift entirely towards other attack types, like business email compromise (BEC), which don't seem to cause as much disruption, but are still very lucrative for their bottom lines."

**About the Author(s)**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

LockBit Ransomware Takedown Strikes Deep Into Brand's Viability

Concrete CMS version 9 below 9.2.8 and previous versions below 8.5.16 is vulnerable to Stored XSS in blocks of type file. Prior to fix, stored XSS could be caused by a rogue administrator adding malicious code to the link-text field when creating a block of type file. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 3.1 with a vector of  AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Thanks Alexey Solovyev for reporting.



Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   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-2024-3180

**Concrete CMS Stored XSS in blocks of type file**

Low severity GitHub Reviewed Published Apr 3, 2024 to the GitHub Advisory Database • Updated Apr 3, 2024

**Package**

composer concrete5/concrete5 (Composer)

**Affected versions**

\>= 9.0.0RC1, < 9.2.8

< 8.5.16

**Patched versions**

9.2.8

8.5.16

**Description**

Published to the GitHub Advisory Database

Apr 3, 2024

GHSA-9qhc-pg6j-wf23: Concrete CMS Stored XSS in blocks of type file

Concrete CMS version 9 prior to 9.2.8 and previous versions prior to 8.5.16 are vulnerable to Stored XSS in the Search Field. Prior to the fix, stored XSS could be executed by an administrator changing a filter to which a rogue administrator had previously added malicious code. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 3.1 with a vector of  AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Thanks Alexey Solovyev for reporting



Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   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-2024-3181

**Concrete CMS Stored XSS in the Search Field**

Low severity GitHub Reviewed Published Apr 3, 2024 to the GitHub Advisory Database • Updated Apr 3, 2024

**Package**

composer concrete5/concrete5 (Composer)

**Affected versions**

\>= 9.0.0RC1, < 9.2.8

< 8.5.16

**Patched versions**

9.2.8

8.5.16

**Description**

Published to the GitHub Advisory Database

Apr 3, 2024

GHSA-qgm9-rxmq-jxmq: Concrete CMS Stored XSS in the Search Field

Concrete CMS version 9 before 9.2.8 and previous versions prior to 8.5.16 is vulnerable to Stored XSS on the calendar color settings screen since Information input by the user is output without escaping. A rogue administrator could inject malicious javascript into the Calendar Color Settings screen which might be executed when users visit the affected page. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 2.0 with a vector of  AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N&version=3.1 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator   

Thank you Rikuto Tauchi for reporting 


Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   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-2024-2753

**Concrete CMS Stored XSS on the calendar color settings screen**

Low severity GitHub Reviewed Published Apr 3, 2024 to the GitHub Advisory Database • Updated Apr 3, 2024

**Package**

composer concrete5/concrete5 (Composer)

**Affected versions**

\>= 9.0.0RC1, < 9.2.8

< 8.5.16

**Patched versions**

9.2.8

8.5.16

**Description**

Published to the GitHub Advisory Database

Apr 3, 2024

Tag

#xss