Security vulnerabilities

A publicly accessible .git directory was discovered on the target domain https://security.alwaysdata.com. This vulnerability allows unauthorized users to download the entire Git repository, potentially exposing sensitive source code, configuration files, credentials, API keys, and historical commit data.

Affected Asset
FieldValueURLhttps://security.alwaysdata.com/.git/Domainsecurity.alwaysdata.comProtocolHTTPSVulnerabilityGit Repository Exposure

Technical Details
Vulnerability Description
The .git directory is a hidden folder that Git uses to store all version control information for a repository. When this directory is exposed on a web server, attackers can reconstruct the entire source code repository, including:

Complete source code files
Historical commits and changes
Developer information (names, emails)
Configuration files that may contain credentials
API keys, database passwords, and other secrets
Internal documentation and comments

Proof of Concept
Step 1: Access the exposed .git directory
curl -I https://security.alwaysdata.com/.git/ Step 2: Check for accessible Git objects
curl -s https://security.alwaysdata.com/.git/HEAD curl -s https://security.alwaysdata.com/.git/config curl -s https://security.alwaysdata.com/.git/index Step 3: Dump the repository using git-dumper or similar tools
bash# Using git-dumper
git-dumper https://security.alwaysdata.com/.git/ ./dumped_repo

# Alternative: Using wget
wget -r -np -nH https://security.alwaysdata.com/.git/ Step 4: Reconstruct and analyze the repository
bashcd dumped_repo
git checkout – .
git log –oneline

Impact Assessment
Confidentiality Impact: HIGH

Complete source code exposure
Potential credential leakage
Internal business logic revealed

Integrity Impact: MEDIUM

Attackers can study the code for additional vulnerabilities
Understanding of security mechanisms enables bypass attempts

Availability Impact: LOW

No direct impact on availability
However, discovered vulnerabilities could lead to service disruption

Business Impact

Intellectual Property Theft: Competitors or malicious actors can steal proprietary code
Credential Exposure: Hardcoded secrets may grant unauthorized access to databases, APIs, or third-party services
Further Exploitation: Source code analysis enables discovery of additional vulnerabilities (SQL injection, XSS, authentication bypasses)
Reputation Damage: Public disclosure of poor security practices
Compliance Violations: Potential GDPR, PCI-DSS, or other regulatory violations

Summary:

Hi team, hope you are doing well.

During security testing of the AlwaysData webmail service, I identified a vulnerability that allows an attacker to send emails while impersonating any AlwaysData user account (e.g., anyuser@alwaysdata.net) without authentication or authorization.

This flaw enables a malicious actor to fully spoof internal user identities via the webmail interface, making the emails appear legitimate and trusted.

Description:

Improper authorization in AlwaysData webmail allows an attacker to send emails on behalf of any registered @alwaysdata.net user without authentication, resulting in unauthorized account impersonation and loss of email integrity across the domain.

Severity:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

7.5 High

Steps to Reproduce:

1. Open the AlwaysData webmail interface.(https://webmail.alwaysdata.com/?from_roundcube=1)

2.Navigate to the (https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=identities)

In the “Email” field, manually specify any valid AlwaysData email address
(e.g., victimuser@alwaysdata.net) that does not belong to the authenticated session.

3. Save it

4. Compose email select the victim mail.

5.Enter any recipient email address.

6.Send the email.

Observe that the email is successfully delivered and appears to originate from the impersonated AlwaysData user, despite no authorization or ownership validation.

Expected Result

The system should restrict the sender address to only the authenticated user’s own email identity.

Actual Result

Emails can be sent using any registered @alwaysdata.net address without authorization.

Poc:

Added short video poc for confirmation

(https://drive.google.com/file/d/1iJY5OQev2Uz2aDDTFBLw3hhnhvYT77xf/view?usp=sharing)

Impact:

This vulnerability allows unauthorized use of trusted @alwaysdata.net email identities, breaking sender authenticity and undermining the integrity and reliability of the AlwaysData email system.

Thanks

Summary: The application exposes the XML-RPC endpoint with the pingback.ping method enabled and accessible without authentication. This allows an unauthenticated attacker to supply an arbitrary external URL, causing the server to initiate outbound network requests.
This behavior was confirmed via an out-of-band DNS interaction using a controlled Burp Collaborator (OAST) domain, demonstrating a Server-Side Request Forgery (SSRF) condition.
Severity: High
Affected Component: •URL: https://blog.alwaysdata.com/xmlrpc.php
•Protocol: XML-RPC •Authentication: Not required
Vulnerability Type: •Server-Side Request Forgery (SSRF)
•XML-RPC Pingback Abuse
Description: The XML-RPC interface allows the pingback.ping method to be invoked without authentication. By providing a specially crafted request containing an attacker-controlled URL, the server performs a DNS resolution and attempts to connect to the supplied domain.
This behavior enables an attacker to coerce the server into making arbitrary outbound requests, which is the core condition of SSRF.
The issue was validated by observing a DNS lookup from the target server to a Burp Collaborator domain, confirming that the request originated from the vulnerable server itself.

Steps to reproduce: 1] Capture the request of this url in burp suite and send it to repeater
https://blog.alwaysdata.com/xmlrpc.php

2] add this injection in the burp suite repeater (add your own collaborator link)
<methodCall>

<methodName>pingback.ping</methodName>
<params>

<param>
<value>
<string>http://collaborator_link</string>
</value>
</param>

  <param><value><string>https://blog.alwaysdata.com/xmlrpc.php</string></value></param>
</params>

</methodCall>

3]Observe Out-of-Band Interaction
The Burp Collaborator server records a DNS lookup originating from the target server:
•Interaction Type: DNS
•Source IP: 185.31.40.97
•And other info
This confirms that the target server processed the supplied URL and initiated a server-side network request.

Impact: An attacker can abuse this vulnerability to:
•Force the server to make arbitrary outbound network requests
•Perform internal network reconnaissance (SSRF scanning)
•Bypass firewall and IP-based access controls
•Leak internal infrastructure behavior
•Abuse the server for reflected or indirect denial-of-service (DDoS) attacks
In certain environments, this may allow access to internal services not exposed to the public internet, increasing the risk of further compromise.

Mitigation: • Disable XML-RPC entirely if not required
• Disable the pingback.ping method specifically
• Restrict XML-RPC access to trusted IPs only
• Validate and allowlist outbound URLs
• Block arbitrary outbound DNS and HTTP requests from the application server

Regards, Vishal Sanjay Jadhav.
Ethical Hacker & Cyber Security Analyst.
vp666159@gmail.com

Summary The application fails to normalize Gmail addresses during signup. Gmail treats email variations involving dots (.) and plus tags (+) as the same address, but the website processes each variation as a unique account.

As a result, an attacker can register unlimited accounts using a single Gmail inbox, bypassing restrictions such as:

one-user-per-email
free trial limits
referral abuse
promo codes
account creation throttling
Proof of Concept (PoC)

Step 1 Sign up with a real Gmail address Email: kalihunter001@gmail.com → Receive verification code. Step 2 Sign up again using a dot variation Email: ka.lihunter001@gmail.com → Also receive confirmation email in the same inbox.

Impact An attacker can:

Create unlimited fake accounts
Abuse free trials or credits
Abuse referral or promo systems
Circumvent limits on number of accounts per user
Spam the system with mass-registered accounts
Evade anti-fraud mechanisms
Potentially escalate privilege in systems that trust email uniqueness
This is a Business Logic Vulnerability that can directly affect revenue, analytics, and operational integrity.

Recommendation (Fix) Normalize email addresses before storing or checking uniqueness:

Remove dots from Gmail usernames
Strip anything after + in the username
Convert to lowercase
Convert googlemail.com to gmail.com
Enforce uniqueness on normalized email
Example normalized form for all Gmail inputs: kalihunter001@gmail.com POC ATTACHED BELOW

Regards Kali Hunter

Target Application: https://help.alwaysdata.com/en/ (Search Function)
Date of Test: December 8, 2025
Tester: Abhishek V
Mail id: abhi18vedamurthy@gmail.com

Description: The search functionality of the test website is vulnerable to SQL injection. A classic payload (OR 1=1;–) was entered into the search field, and the application returned 94 results, indicating that the input was directly concatenated into a SQL query without proper sanitization or parameterization.

Steps to Reproduce:
1. Navigate to the target website.
2. Locate the search input field.
3. Enter the following payload with a space after the double – OR 1=1;–
4. Submit the search.
Observation: 94 results are returned, bypassing any intended filtering logic.

Impact Assessment
1. Risk Level: Medium to High depending what results are returned
2. Potential Impact:
a. Unauthorized data access
b. Data leakage or manipulation

Recommended Remediation
1. Input Validation and Escaping
2. Reject or sanitize unexpected characters in user input.
3. Rejecting the statements that have the syntax of SQL queries.

POC: Refer to the video attachment named SQLi

Title

Critical Exposure of alwaysdata.com User Credentials via Alien TxtBase (Plaintext Passwords, Emails & Phone Numbers)

URL

Multiple alwaysdata endpoints are present in the leak, including:

https://alwaysdata.com/

https://alwaysdata.com/fr/inscription

https://alwaysdata.com/fr/inscription/

https://alwaysdata.com/en/register

https://alwaysdata.com/en/register/

https://alwaysdata.com/en/signup/account/

https://alwaysdata.com/fr/signup/account/

https://alwaysdata.com/fr/signup/

https://alwaysdata.com/en/marketplace/bookstack/

Evidence spread across all uploaded LeakBase / Alien TxtBase HTML files.

Description

The uploaded Alien TxtBase datasets show large-scale exposure of alwaysdata.com account credentials, collected by infostealer malware that steals browser-saved logins.

Across all the files, there are hundreds of entries for alwaysdata.com, including:

Emails (Gmail, Hotmail, Yahoo, corporate domains, etc.)

Plaintext passwords

Nicknames / device usernames

Phone numbers in some entries

Direct registration and signup URLs on alwaysdata.com

Examples of leaked patterns (all values redacted here):

Email + password + registration link, e.g.:
Email: …@gmail.com / Password: Fahendrena / Link: alwaysdata.com/fr/inscription

5202727960

Password + nick + registration URL (no email), e.g.:
Password: Footballclub972 / Nick: nathanv / Link: alwaysdata.com

5202727960

Email + password + /en/register or /fr/signup/account URLs, e.g. multiple developer / project owner accounts

Entries including phone number and “App: alwaysdata.com” metadata

The data confirms that real alwaysdata.com user accounts, including hosting users, developers and small businesses, have their credentials exposed in plaintext in a public leak collection.

While the initial compromise is on user devices (infostealers), the effect is a direct, ongoing compromise of alwaysdata.com accounts, as the credentials are valid and can be reused by attackers at any time.

Impact

Severity: CRITICAL

1. Full Account Takeover (ATO)

Attackers can use any email/password pair from the logs to log into alwaysdata.com and:

Access hosting control panels for websites and apps

Modify or delete customer sites

Inject malicious content, phishing pages, or malware

Change account email, password, and billing details

Because passwords are in clear text, there is no need for cracking or guessing.

2. Website & Application Compromise

As alwaysdata is a hosting provider, compromised accounts may be:

Production sites for individuals, startups, and small businesses

Internal dashboards or admin panels

Hosted APIs or backends

This allows attackers to:

Deface or replace websites

Steal data from web applications

Use compromised infrastructure for further attacks (phishing, malware hosting, C2, etc.)

3. Reputational & Legal Risk

Leaked credentials include:

Emails

Passwords

In some cases, phone numbers

This exposes alwaysdata users to:

Identity theft

Targeted phishing

Credential reuse on other services

It may also create privacy and regulatory exposure for alwaysdata if not addressed (e.g., GDPR if EU users are affected).

4. Ongoing Automated Exploitation

Alien TxtBase:

Is widely shared through Telegram breach channels

Is integrated into OSINT and credential-stuffing tools

Is resold on dark-web marketplaces

This means alwaysdata.com accounts will be continuously targeted, not just once.

Evidence (Redacted)

Representative examples from the uploaded leak files (all real, but anonymized):

Email: <redacted>@gmail.com Password: Link: alwaysdata.com/en/register/

5202727960

Password: Nick: Powerbyte
Link: alwaysdata.com/fr/signup/account/

Email: <redacted>@hotmail.com Password: Link: alwaysdata.com/fr/inscription/

Email: <redacted>@gmail.com Telephone: <redacted>
App: alwaysdata.com

No raw passwords, emails or phone numbers are reproduced in this report.

Recommendation
Immediate

Force password reset for all alwaysdata.com accounts whose credentials appear in Alien TxtBase.

Invalidate active sessions and login cookies for those users.

Alert affected users and advise them to:

Clean their devices of infostealer malware

Change reused passwords on other platforms.

Short-Term

Implement breached-password protection:

Block login with passwords known to be exposed in public leaks (including Alien TxtBase).

Enforce or strongly encourage MFA for all alwaysdata accounts.

Add rate limiting and bot protection on login, signup and password reset endpoints.

Monitor for abnormal login patterns from known bad IP ranges or TOR exit nodes.

Long-Term

Move toward passwordless authentication (WebAuthn / security keys) for control-panel access.

Deploy continuous dark-web / Telegram breach monitoring for “alwaysdata.com” credentials.

Provide security guidance for customers (blog / documentation) on:

Risks of storing passwords in browsers

Infostealer malware

Using password managers and MFA.

Summary:

After enabling 2FA, during login the system asks for email, password, and then a valid 2FA code. When a valid 2FA code request is captured and sent through Burp Repeater, sending multiple parallel copies of the same request returns multiple valid 2FA responses for a single correct code. These valid responses can then be replayed at any time to bypass the 2FA challenge completely. As a result, an attacker can repeatedly access the account without entering any new 2FA code, fully bypassing the authentication layer.

Steps to Reproduce:

Enable 2FA on your account.

Log out and attempt to log in again.

Enter a valid email and password.

When the system asks for the 2FA code, enter a valid code and capture this request in Burp Suite.

Send the 2FA request to Burp Repeater and create multiple parallel copies.

Send all parallel requests simultaneously — observe that the server returns multiple valid 2FA success responses for one single valid code.

Now try logging in again: enter any invalid 2FA code.

Capture the invalid response and replace it with one of the previously captured valid parallel responses.

Forward the modified response — you will gain full account access without needing a new 2FA code.

This method works repeatedly.

Impact :

This vulnerability breaks the entire 2FA security model. By replaying the multiple valid responses generated from a single 2FA code, an attacker can repeatedly log in without providing any fresh 2FA code. This completely bypasses multi-factor authentication, rate limiting, and OTP expiration logic, allowing persistent unauthorized access to any protected account.

Note: Please don't disclose this report

Description: User A can raise a Closure Request to user B's task.

Steps to Reproduce: 1. Create two accounts A and B in Bug Tracking Interface.
2. From each account create a task.
3. Now turn of Burp Suite intercept, from account A click on "Request Closure" and enter a reason, then submit.
4. Change the task id of user A to user B's everywhere in the request, intercept response, then click forward.
5. Will see status code "200 OK" confirming the request has been made, turn off intercept.
6. Now go to account B see the request is successful and the reason is also added as shown in POC-4.png.

For any further information please let me know.

Regards,

Vulnerability
The password-reset endpoint https://admin.alwaysdata.com/password/lost/ accepts unlimited requests for any e-mail address without rate limiting, CAPTCHA, or cooldown.

Impact
- An attacker can flood any user’s mailbox with hundreds/thousands of password-reset e-mails
- Targeted denial-of-service against a specific user
- PTP (Password-reset Token Poisoning) & Password Reset Abuse
- Loss of trust and bypassing of normal security controls

Steps to Reproduce
1. Go to https://admin.alwaysdata.com/password/lost/ 2. Enter any valid e-mail address that has an alwaysdata account
3. Capture the request in Burp Suite / Intruder
4. Send it to Intruder, remove all payloads except the e-mail parameter
5. Start the attack with multiple threads
→ The victim instantly receives a flood of password-reset e-mails (see attached PoC video/screenshots)

Proof of Concept
(Attach your video or screenshots here – click “Choose File”)

Recommended Fix
Implement at least one of the following on the password-reset endpoint:
- Strict per-IP + per-e-mail rate limiting (e.g., max 3–5 requests per hour)
- CAPTCHA (hCaptcha/reCAPTCHA)
- Temporary account lockout after X attempts

Researcher: TrinityXploit

vulnerability name : open redirection

url: https://admin.alwaysdata.com/login/?next=%2f

step to reproduced:
1.intercept the url
2.enter bing.com in the parameter
3. on location you see that response will shown on location bing.com

for furthur info please see the screenshot

Thank you
Anant

Summary

A DOM-based Open Redirection vulnerability was identified on the target application. The issue allows an attacker to manipulate client-side JavaScript to redirect users to arbitrary external domains. This can be exploited for phishing, social engineering, or chaining into more severe attacks.

Affected URL https://www.alwaysdata.com%2f@evil.com/

Steps to Reproduce
Navigate to the following crafted URL:
https://www.alwaysdata.com%2f@evil.com/

Observe that the application’s client-side code interprets the encoded path (%2f) and @evil.com portion incorrectly.
The browser resolves the URL in a way that causes redirection to the attacker-controlled domain (evil.com).
This behavior occurs without server-side validation, indicating a DOM-based flaw.

Impact

Phishing attacks: Users can be tricked into believing they are visiting a trusted domain ( www.alwaysdata.com ) but are redirected to a malicious site.
Session hijacking: If combined with other vulnerabilities (e.g., cookie theft, XSS), attackers can escalate impact.
Reputation damage: Users may lose trust in the brand if exploited in phishing campaigns.

**Recommended Fix

Implement strict validation and sanitization of client-side URL parameters.
Use a whitelist of allowed redirect domains.
Encode and validate user-controlled input before processing in JavaScript.
Avoid relying on DOM methods (location, document.URL, etc.) without proper sanitization.

vulnerability name : csrf where attacker can use unused token to access victim account

description: attacker can use same csrf token to login into an account that might take account takeover vulnerability

step to reproduced:
1.make two account with different email
2.intercept one mail account and copy its csrf token and drop the response
3. change that token with another account and login with 2nd account

for furthur info please see the poc

Thank you
Anant

Description:

The /user/delete/ endpoint allows deleting an account by sending a POST request. By replacing the sessionid cookie with that of another user, it is possible to delete any user account without knowing their password or performing any authentication.

This indicates a broken authentication / session management vulnerability where the server blindly trusts the sessionid cookie for critical actions.

Steps to Reproduce:

1.Log in as the victim account.

2.Obtain the victim’s sessionid.

3.In another browser/session, log in as the attacker.

4.Capture the delete account request: POST /user/delete/

5.Replace the attacker’s sessionid in the Cookie header with the victim’s sessionid.

6.Send the modified request.

7.Observe that the victim account gets deleted.

“Note: An attacker can brute-force these session IDs with the help of AI.”

Impact:

An attacker can delete any user's account by guessing or brute-forcing session IDs and using them in the delete request.

*Any attacker with a valid sessionid can delete any user’s account.

*No password, no verification, no re-authentication.

*Leads to complete account loss and permanent data deletion.

Severity: Critical (P1).

Recommended Fix:

*Bind session to user identity server-side and reject modified session cookies.

*Require full re-authentication (password) for account deletion.

*Add strict CSRF validation and session consistency checks.

Hello Team,

My last bug on no rate limit was closed due to duplicat. Here i am sending you one more no rate limit vulnrability

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.

## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://mailman.alwaysdata.com

step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

Thank you

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.
In case a client made too many requests within a given timeframe, HTTP-Servers can respond with status code 429: Too Many Requests.
## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://admin.alwaysdata.com/password/lost/ step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

no task description

Hello Team,

Summary:
There exists a Race Condition in which the subscription are added multiple times which will make them unremovable. As you know, same subscription is not added in admin.alwaysdata.com, but through race condition same subscription can be added multiple time and admin can't remove that in which another user are created them.

Steps To Reproduce:

1. Go to https://admin.alwaysdata.com/transfer/add/?type=account.
2. Fill the form which have new owner(for e.g: example@gmail.com) and click on validate it.
3. Go to admin.alwaysdata.com and login your account example@gmail.com. 4. Then go to https://admin.alwaysdata.com/transfer/ and accept the transfer request and intercept the request on Burpsuite.

5.Make 10 to 15 request and group them to send it from repeater.
6. You can see that any subscription are added and if want to delete them you can't.

Impact
Irremovable/permanent subscription. Even the admin cannot remove that subscription in which another user created it in that account.

Thank You,

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.

Description: After unlinking Google from a user's account, previously created sessions via Google remain active and are not terminated.

Steps to reproduce:

1. Browser A: Sign in to the account via Google OAuth. Keep the session.

2. Browser B: Sign in to the same account using email/password.

3. From Browser B, go to account settings and unlink Google.

4. Return to Browser A and notice that the session was not terminated.

POC: https://admin.alwaysdata.com/support/90046/

Impact:
An attacker who possesses a previous session via Google remains able to access the account even after the owner believes they have unlinked it — leading to persistent unauthorized access.

Suggestion for fix:

Force immediate logout from all sessions associated with the OAuth provider.

Description:
While testing the ticket feature in the support system, I noticed that the sender’s IP address is visible to all users participating in the same ticket. This behavior leads to an unjustified exposure of sensitive information and constitutes a violation of user privacy, as the IP address can reveal the user’s approximate location and service provider.

Steps to Reproduce:

1. Create a new support ticket.

2. Add another user to the same ticket.

3. Send a message from user account (A).

4. Observe that the IP address of user A appears next to the message and can be seen by the other user.

POC:
https://admin.alwaysdata.com/support/89988/

Impact:
Any participant in the ticket can view the IP address of other users.
This is a clear violation of user privacy and conflicts with data protection policies and laws.

Recommendation:
Hide the IP address from regular users and make it visible only to support staff or administrators.

Summary:
The session management does not include any IP address, geolocation, or device fingerprinting checks. Once a session token is obtained, it can be replayed from any device, browser, or country, allowing attackers to bypass contextual integrity checks and maintain unauthorized access.

Steps to Reproduce:
Log in to alwaysdata.com and capture the session token (e.g., via browser DevTools or proxy).

Move to a different device, browser, or VPN geolocation.

Replay the captured token (e.g., by importing cookies or using the token in API headers).

🎯 Result: The session remains valid — no reauthentication, MFA challenge, or warning is triggered.

Impact:
Allows session hijack from another country or device without detection.

No context-aware defense such as:

IP or ASN consistency checks

Browser/device fingerprinting

Geo-velocity anomaly detection

Supports stealthy unauthorized access, even if login alerts or 2FA are present.

Summary:
The OAuth implementation relies solely on bearer tokens (RFC 6750). Bearer tokens act like “keys to the kingdom” — anyone holding them gets full access. Without Proof-of-Possession (PoP) or sender-constrained tokens, a stolen token can be reused by an attacker from any device, IP, or session.

Steps to Reproduce:

Log in to the alwaysdata.com application and obtain a valid bearer access token (e.g., via browser dev tools).

Replay the same token from a completely different environment:

Another browser,

Another machine,

Or a proxy/intercepting tool.

Observe that the API/service still accepts the token without verifying the device, TLS channel, or binding key.

Impact:

Token Replay Attacks: Stolen tokens from XSS, CSRF, or insecure storage can be reused by attackers.

Session Hijacking: An attacker can impersonate users indefinitely until the token expires/revoked.

High-Severity Risk: Any token leak = full account compromise.

Summary:
The application allows users to reuse their existing password when performing a password change or password reset. This undermines the security intent of these features, as users can bypass the enforcement of setting a new, stronger, and unique credential. Allowing password reuse increases the risk of account takeover, brute-force persistence, and failure to comply with security best practices (such as NIST SP 800-63B and OWASP ASVS), which explicitly recommend preventing the reuse of the same password.

Steps to Reproduce:

Log in to the alwaysdata.com application using valid credentials.

Navigate to the Change Password or Password Reset functionality.

Enter the current password in both the "Old Password" and "New Password" fields (or set the reset password to the same as the old one).

Observe that the operation succeeds, and the password remains unchanged.

Impact:

Defeats the purpose of password change/reset: attackers with leaked or compromised credentials can maintain persistence by resetting to the same password.

Increases susceptibility to brute force and credential stuffing, since the password remains weak or already compromised.

Violates industry-standard best practices for credential management (OWASP, NIST).

Reduces the effectiveness of incident response: if credentials are suspected to be exposed, forcing a reset but allowing reuse leaves accounts vulnerable.

Security Best Practices Reference:

NIST SP 800-63B: Recommends preventing password reuse and enforcing that new credentials differ from previously used ones.

OWASP ASVS 2.1.8: Applications should prevent the use of the same value as the current password when changing or resetting credentials.

Recommendation:

Implement a password history check to ensure that newly set passwords are different from the current one.

Enforce a configurable password history (e.g., last 3–5 passwords cannot be reused).

Provide appropriate user feedback when the entered password matches the old one.

Severity: High – This is a critical flaw because it undermines a fundamental security control designed to mitigate account compromise.

Summary
The application applies rate limiting on failed login attempts per IP address, but does not combine this with account- or device-based throttling. An attacker can rotate IP addresses (using VPNs, proxies, or botnets) and continue brute-force or credential stuffing attempts against the same account, effectively bypassing the rate limit. This allows high-volume automated attacks that can lead to account takeover, credential stuffing success, and large-scale account enumeration.

Steps to Reproduce
In the alwaysdata.com application, choose a target account (e.g., victim@example.com).

From IP A, submit the maximum allowed failed login attempts until the application rate-limits further attempts from IP A. Record the response/status code.

Switch to IP B (use VPN, proxy, or other IP rotation technique).

Attempt to authenticate to the same target account using different password guesses. Observe that attempts from IP B are accepted and counted separately (rate limit not enforced per account).

Repeat with IP C, IP D, etc., and observe continued unrestricted attempts against the same account.

(Optional) Automate steps 2–4 from a list of rotating IPs to confirm large-scale brute-force is possible.

Expected secure behavior: The system should limit authentication attempts per account (or per account+device fingerprint) in addition to per-IP limits.
Observed insecure behavior: Authentication attempts continue after IP rotation; rate limiting is effectively bypassed.

Impact
Account Takeover (High): Continuous attempts across rotated IPs increase the probability of successfully brute-forcing a password or succeeding with credential stuffing.

Mass Credential Stuffing (High → Critical): Attackers can target many accounts at scale by cycling IPs, causing large-scale account compromise.

Recommended Fixes
Enforce account-based throttling (primary)

Track failed authentication attempts per account (email/username) and apply progressive throttling or temporary lockouts. Example policy: after 5 failed attempts for an account within 15 minutes, block further attempts for that account for 15 minutes.

Combine IP + account limits (defense-in-depth)

Use a hybrid key: limit_key = hash(account_id + ip) plus a separate limit_key = account_id. This reduces false positives while preventing IP-rotated attacks.

Severity:
High

Summary:
OAuth account linking occurs automatically and implicitly on the company's web application, without requiring user verification, which can enable account takeover. Suppose an attacker signs up using OAuth with the same email as an existing account (registered via email/password). In that case, they are granted access to that existing account without any ownership validation, which is a critical authentication flaw.

Steps to Reproduce:
Create a target account (victim):

Go to alwaysdata.com

Register a new account using email/password, e.g., victim@example.com.

Log out.

Trigger the issue (attacker):

Go to the website

Log in using an OAuth provider (e.g., Google or Apple) that uses the same email address: victim@example.com.

Observe:

The OAuth login automatically links to the existing account created via email/password.

No verification (like password prompt, email confirmation, or user consent) is required.

The attacker now has full access to the victim's account.

Impact:
This vulnerability allows an attacker to fully compromise accounts by using an OAuth provider with an email address matching an existing account, without needing the victim’s password or any verification step.

Possible consequences:

Unauthorized access to personal data.

Tracking information leakage

Service misuse or device control.

Breach of privacy and user trust.

Recommended Fixes:
Do not auto-link OAuth accounts based solely on email.

Prompt the user for verification when an existing account with the same email exists (e.g., via:

Password input,

Email confirmation,

Explicit linking process in settings).

Provide clear UI/UX for account linking that ensures user intent.

Suggested CVSS (3.1) Score:
8.8 (High)

Attack Vector: Network

Attack Complexity: Low

Privileges Required: None

User Interaction: None

Confidentiality Impact: High

Integrity Impact: High

Availability Impact: Low

Regards,
Mehedi Hasan