All Projects

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

#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

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.

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.

Report Summary:
I discovered a potential security issue where sensitive data is accessible via a URL archived by the Wayback Machine. The URL exposes an invoice containing personal and financial information, which could be misused if accessed by unauthorized individuals.

Details of the Issue:

1.Source of URL: Wayback Machine (Internet Archive)

2.URL: https://admin.alwaysdata.com/billing/337102/pdf/?user_id=150041&token=1657692793-a13e927142b2d5d7f427

3.Exposed Data:

4.Personal Information: Name (Simon Amour), email address (simondiligues@outlook.com).

5.Financial Information: Invoice amount (€100.00), bank account details (IBAN: FR76 1027 8060 4100 0205 8810 110, BIC: CMCIFR2A).

6.Service Details: Public Cloud service (10 GB) for the period 13/07/2022 to 27/07/2023.

7.Reference Numbers: Invoice reference (220713337102), user ID (150041), and token (1657692793-a13e927142b2d5d7f427).

Steps to Reproduce:

1.Access the URL via the Wayback Machine.

2.The PDF invoice containing sensitive data is directly accessible without additional authentication.

Impact:
This issue could lead to unauthorized access to sensitive personal and financial information, potentially resulting in identity theft, financial fraud, or other malicious activities. The fact that this data is archived on a public service like the Wayback Machine increases the risk of exposure.

Summary:
A critical security vulnerability was identified in the file upload on the application. The flaw allows users to upload any file type, including executable files like .pdf, .php, and .exe, with invited members. This presents a significant risk, as malicious files could be uploaded and distributed, leading to potential exploitation and compromise of other systems.

Vulnerable url: https://admin.alwaysdata.com/support/add/

Description:

I discovered a publicly accessible PDF file containing sensitive financial and personal information at the following URL:
https://share.alwaysdata.com/IBAN.pdf AND https://static.alwaysdata.com/docs/IBAN.pdf

The document exposes Personally Identifiable Information (PII) and sensitive banking details, including the International Bank Account Number (IBAN), Bank Identifier Code (BIC), account holder's name, and address. This information could be exploited for unauthorized transactions, fraud, and privacy violations.

Steps to Reproduce:

1. Navigate to the URL: [https://static.alwaysdata.com/docs/IBAN.pdf] and [https://share.alwaysdata.com/IBAN.pdf]
2. Download the file (IBAN.pdf).
3. Open the file to view the sensitive details

Impact:

• Financial Risks: An attacker could misuse the exposed banking details for unauthorized transactions or fraudulent activities.
• Privacy Concerns: The document discloses the account holder’s name and address, increasing the risk of phishing or other targeted 
        attacks.
• Legal Compliance: Public exposure of such information may violate data protection regulations, such as the GDPR (General Data 
        Protection Regulation) in the EU.

Mitigation:

1. Immediately remove the file from public access.
2. Audit all publicly accessible files to ensure sensitive information is not exposed.
3. Use preventive measures like robots.txt or noindex tags to prevent indexing by search engines.
4. Review the system to ensure sensitive files are stored securely and not inadvertently exposed.

Severity: High – This issue involves the public disclosure of sensitive financial and personal information, which could lead to significant harm if exploited.

Suggested Timeline for Fix: Immediate – This issue should be prioritized for resolution to prevent potential abuse.

Hope this will be fixed soon.
Do let me know if you need any further assistance.

NOTE: While Making this report public please make sure to mask or remove the sensitive information that is written in the report.

Thanks
Best Regards
Aakarsh Mishra

Hope everything going well on your side.

Recently, while enumerating over alwaysdata.net and alwaysdata.com i came across a js file which contain a npm dependency which you also used using command require('nw.gui') . When i check it on npm registry it does not exist over there. So i claimed it. I also came across other dependencies which are used in other js files with the exact syntax but they are already exist on npm registry but only this dependency does not exist over npm registry. So, it could easily result in npm dependency confusion vulnerability which could severe consequences like if anytime you update/install it will easily give rise to Remote Code Execution over user/developer system even if it in scope or not.

## Step to reproduce:

1. Enumerate over your domain and find all endpoints.
2. From endpoints extract all js files.
3. In JS files search npm dependecies.


4. You will find dependency which I mentioned above.


Follow this js-file : [Link](https://foxrewards.alwaysdata.net/jeu/js/rpg_core.js)
5. Claimed the dependency.


## Impact:

1. If anytime you update/install it will easily give rise to Remote Code Execution over user/developer system which could be fatal.
2. Reputation damage of the company.

## Mitigation
Once you have reviewed this report, I can unclaim the package and you can upload your own ones there.

Failure to invalidate session after password change

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/mailbox/id/ and set a password and then submit.
2.Then, go to another browser and login into https://webmail.alwaysdata.com/?from_roundcube=1.
3.Again go to https://admin.alwaysdata.com/mailbox/id/ and then change the password and submit it.
4.You can see that session is still login in https://webmail.alwaysdata.com/?from_roundcube=1 and you can make any Changes in https://webmail.alwaysdata.com/?from_roundcube=1.

Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can complete access your account till that session expires! So, your account remains insecure even after the changing of password.

Thank You,

Waleed Anwar

Direct accessing Api on another Browser.

Hello Team, I hope you are doing well. Well, researching in your domain I found Direct accessing Api on another Browser, steps are given below:

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/ and login into your account.
2 Go to Profile Section and create your token.
3.Then, go to https://api.alwaysdata.com/v1/account/ and sign in into your account.
4.Copy your login account Url and paste it into another browser, you can see that you can direct accessing the account without sign in the account.

Impact:

Create another session into another browser for accessing the account, If attacker gain the victim session or laptop access, so he/she can directly access the victim Api account in https://api.alwaysdata.com/v1/account/ .

#Note:

I deleted all the cookies from the browser, after that I visit in https://api.alwaysdata.com/v1/doc so I can directly accessing the account without sign in again.

Thank You,

Waleed Anwar

https://security.alwaysdata.com/.git/config

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://github.com/flyspray/flyspray.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

https://security.alwaysdata.com/.gitignore

flyspray.conf.php
img/veloz.png
attachments/*
/.idea/
/nbproject/*
vendor/*
composer.lock
composer.phar
/_site/
.htaccess
*.PHPEditProject
/avatars/*
/lang/*.php.bak
/lang/*.php.safe
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

https://security.alwaysdata.com/.git/logs/HEAD

0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ 1704809861 +0100    clone: from https://github.com/flyspray/flyspray.git

.gitignore
.travis.yml
LICENSE
README.md
SECURITY.md
includes/.htaccess
cache/index.html
fonts/index.html
caddy.dist
composer.json
...
...
themes/CleanFS/templates/reports.tpl
themes/CleanFS/templates/roadmap.text.tpl
themes/CleanFS/templates/roadmap.tpl
themes/CleanFS/templates/shortcuts.tpl
themes/CleanFS/templates/toplevel.tpl
themes/CleanFS/theme.css
themes/CleanFS/theme_print.css
themes/CleanFS/typography.css
themes/CleanFS/up.png
vendor/.htaccess

Conclusion

• Git index allows accessing the files list and source code through .git/objects/
• You can see the top of the list of files above
• I haven't accessed those files' content because it's not necessary for the report according to the Responsible * Disclosure policy.
• My assumption is that some of those files contain sensitive information, which can be used to escalate vulnerability.

Resolving suggestions

1. Remove access to the .git folder from the web, e.g. in webserver config or using .htaccess file
2. Review repository content considering all data compromised because it has been available in public for a while.

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

Summary:

During testing, I discovered that the 2FA (Two-Factor Authentication) feature can be abused to block legitimate users from registering on the platform. This vulnerability arises because the application allows users to update their email addresses without disabling 2FA. When users update their email while 2FA is enabled, the application requires the 2FA code to log in with the new email. An attacker can exploit this flaw by registering an account using his email, enabling 2FA, and then updating the account's email to the victim's. This process effectively locks the victim out of their email address and prevents them from registering to the platform.

Steps to Reproduce:

1. create account at : https://admin.alwaysdata.com/admin/details/

1. The attacker creates an account using their email address.

1. the attacker logs in and enables 2FA.

1. The attacker then updates their email address to the victim's.

1. If the victim tries to register an account using their email address, they receive an error stating that the email already exists.

1. If the victim attempts to reset the password using the "Forgot Password" feature:

1. The victim receives the password reset link and successfully updates their password.

1. Upon attempting to log in, the application prompts for the 2FA code.

1. Since the victim cannot access the 2FA code the attacker sets, they cannot log in.

PoC :

https://drive.google.com/file/d/1iKnoKLZXCREeIidrOzvH2SXDNDLPqsLH/view?usp=sharing

Impact

This behavior effectively locks the victim out of their email address, preventing them from registering or accessing an account on the platform.

Non-functional 2FA recovery codes

Hello Team,

I hope you are doing well. While researching in your domain https://admin.alwaysdata.com/ I found that their is Non-Functional 2FA recovery code option in your domain.

The users that had enabled 2FA were not able to recover their accounts in case of a missing phone or authentication device. The issue was caused by improper error handling on the client during account recovery.

You should add a back-up recovery option so user or customer should back-up their account easily.

Thank You,

Waleed Anwar

The endpoint is not publicly visible through the application interface but was discovered using search engine dorking techniques.

https://tracker.alwaysdata.com/index.php?module=CoreAdminHome&action=optOut&language=en

Low severity as it doesn't reveal sensitive server info

Session Fixation on admin.alwaysdata.com

Hi Team, I hope you are doing well. While researching in your domain i found Session Fixation vulnerability.

Steps To Reproduce:

Step-1: Open up Firefox & download Cookie Editor Extension on your browser.
Step-2: Go to https://admin.alwaysdata.com/login/?next=/ & login with your credentials.
Step-3: Click on "Cookie Editor" then, click on "Export cookie" by clicking this we get a cookie copied in clipboard.
Step-4: Open another browser or Private tab.
Step-5: Go to https://admin.alwaysdata.com/login/?next=/ but don't login. Just simply click on "Cookie editor" & click on "Import cookie" & paste the code which we previously exported.
Step-6: After pasting just refresh the page and then scroll down and click on register and after scroll down again and click on Already registered?Login and you can see you logged in into the account.

Impact:
A successful session fixation attack gives the attacker access to the victim's account. This could mean access to higher level privileges or the ability to look at sensitive data.

Note: Attacker can use a link or create a login page and send to the user by social media or anyother way for hijacking the session.

Thank You,

Waleed Anwar

Hello Team, I hope you are doing well, while researching in your domain i found Blind SSRF and Open Redirection in Comment Section.

Steps:

1.https://blog.alwaysdata.com/2018/09/20/teaching-program-for-better-it-courses/comment-page-1/ 2. Fill the form and add evil.com or your burp Collab in Website Field.
3.Then Click on Post Comment to post your comment in website.

You can see your comment is posted in the website, when you click on the username in the post it will redirect you in the attacker website or in burp collab you get dns and http responses.

Attacker can host your malicious website in comment section to redirect a user in their website for stealing stuffs etc.

#Note:

It can also vulnerable for clickjacking.

Thank You,

Waleed Anwar

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

Issue with password change

Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.

When a password is changed in user's profile, then a notification about password change is sent to the user (email).
However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.

Note:

Second time i am reporting this issue to you, please make a test account and do that thing in your end so you clearly understand about it.

Thank You,

Waleed Anwar

Hello Team,

I hope you are doing well. While Researching in your domain, I found Subscription not transferred error in your domain.

#Steps to Reproduce:

1: Create profile in "https://www.alwaysdata.com" of owner.
2: Go to "https://admin.alwaysdata.com/Subscription" and open a new account and submit your subscription whatever you want.

3: Then go to "https://admin.alwaysdata.com/permission" and add a user then submit your permission your permission to the user.

4:Again go to "https://admin.alwaysdata.com/Subscription" and click on transfer to another user button to transfer the subscription to the user and then click submit button.

5: Then go to "https://admin.alwaysdata.com/details" and click on Delete this profile button to delete the profile of owner and click on submit button.

Owner assume that he/she transferred the subscription to the user but unfortunately it was not transferred to the user. User only received the notification in their profile and email only of transferred subscription.

Impact:

There is a error of Subscription is not transferred before deleting the profile which may impact to the owner account subscription.

Thank You,

Waleed Anwar

Missing rate limit for current password field (Password Change) Account Takeover:

Vulnerability:
Missing Rate Limit for Current Password field (Password Change) Account Takeover
Steps to reproduce the bug:
1)Go to Profile > Password. Enter any (wrong password) In old password filed.
2)Now enter the new password and Turn the Intercept ON.
3)Capture the request & Send the request to Intruder and add a Payload Marker on the current password value.
4)Add the payload for the password field having a list of more than 100 password or more for test and start attack.
BOOM!
Screen shot is attached as a proof of concept.
Impact
There is no rate limit enabled for "Current Password" field on changing password on your website. A malicious minded user can continually tries to brute force an account password. If user forget to logout account in some public computer then attacker is able to know the correct password, and also able to change the password to new one by inputting large number of payloads.

Thank You,

Waleed Anwar

Unveiling an IDOR Vulnerability in Email Verification Workflows:

Hello Team, I hope you are doing well. Well, i found a idor vuln in email verification workflow in your doamin.

The Vulnerability
1. Step 1: Create an Account with a Fake Email (Email 1)
Like many web services, the platform I was testing does not required users to verify their email addresses upon registration. I created an account using a random, unverified email address, let’s call it email1@example.com.

2. Step 2: Change the Email Address to a New One (Email 2)
Next, I went to the account settings and attempted to change the email address to a new one, email2@example.com, without verifying email1@example.com. The system allowed me to enter a new email.

3. Step 3: IDOR Exploitation
Here’s where things got interesting. I can use email2@example.com without any verification or any notification which was not sent to that email2@example.com for verification. But due to an IDOR vulnerability, the system skipped this step entirely and automatically considered email2@example.com as verified

This meant that I, as an attacker, could verify someone else’s email (Email 2) that I had no control over, effectively gaining control of that account’s new email without ever needing access to it.

The Impact
This IDOR vulnerability presents significant risks, including:

Account Takeover: By exploiting this flaw, an attacker can hijack accounts by swapping the victim’s email with one of their own.
Phishing and Fraud: Attackers could use the new email to perform phishing attacks, tricking users into divulging sensitive information.
Loss of Control: Users might lose control over their accounts since the new email is verified without their knowledge or consent.
Root Cause
The root cause of this vulnerability lies in the system’s failure to validate the ownership of the new email address before considering it verified. Once the first email is verified, the system should force a re-verification of any newly entered email addresses to prevent this kind of exploitation.

How to Prevent It
Here are a few recommendations to mitigate this type of IDOR vulnerability:

Re-verify New Emails: Ensure that when users attempt to change their email addresses, the new email must be verified before it becomes active.
Strict Access Control: Always implement strong access controls to ensure that a user cannot modify objects (in this case, email IDs) they do not own.
Thorough Input Validation: Validate user inputs and ensure proper checks for email ownership before performing any sensitive actions.
Security Audits: Regularly conduct security audits and penetration testing to identify potential IDOR vulnerabilities and other security flaws.

Thank You,

Waleed Anwar

Issue with password change

Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.

When a password is changed in user's profile, then a notification about password change is sent to the user (email).
However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.

Thank You,

Waleed Anwar

Target:alwaysdata.com

Vulnerability Type:Sensitive Credential Exposure

Severity:CRITICAL

Overview:During an OSINT investigation using a custom tool designed to collect data from dark web forums, I identified exposed credentials of users from alwaysdata.com were leaked This poses a significant security risk to the organization. Attached is the txt file with the credentials I found.

Remediation:
Reset all compromised user passwords immediately
Enforce multi-factor authentication
Monitor for signs of account compromise and unauthorized access
Notify impacted users to update credentials

Impact:
Mass account takeovers by attackers
Breach of personal data and intellectual property
Financial fraud and illegal activities using compromised accounts
Potential lateral network compromiseBrand damage, legal liabilities, regulatory violations

Poc :

https://drive.google.com/drive/folders/1Ox0JvlCLy--RDErIj7y9GzGLwoAY7PQL?usp=sharing