All Projects

Severity: High
Due to public exposure of credentials, cryptographic secrets, and insecure runtime configurations.

Affected Component:
Django application configuration file: settings.py
Public GitHub repository (source code exposure)

Vulnerability Summary:
The application’s Django configuration file (settings.py) contains multiple sensitive secrets and insecure configurations that are publicly accessible via a GitHub repository. These include:
Hardcoded database credentials (username & password)
External database host information
Hardcoded Django SECRET_KEY
Debug mode enabled (DEBUG = True)
Although some configurations are commented, they are still exposed to anyone with access to the repository, which represents a serious security risk.

Description:
The Django SECRET_KEY, which is used for cryptographic signing and session security, is hardcoded in a publicly accessible repository.
SECRET_KEY = 'django-insecure-yt()50-c2ul547)8_eu$%@o7)-w=aj809ocuparihd#b+)_70w'

MySQL Database Credentials (Critical)

# DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.mysql',
# 'NAME': 'secu_bdd',
# 'USER': 'secu',
# 'PASSWORD': '<REDACTED>',
# 'HOST': 'mysql-polytech.alwaysdata.net',
# 'PORT': '3306',
# }
# }

Githuh Url: https://github.com/<REDACTED>
( you can check it

Also i have attached some pictures of it you can check it…..

Impact:
Unauthorized database access
Disclosure of sensitive user data
Data modification or deletion
Potential full application compromise
High likelihood of credential reuse across environments

Affected Endpoint: https://admin.alwaysdata.com/ Severity: Medium
Functionality: Database user provisioning
Affected Services: RabbitMQ, PostgreSQL, MySQL

Vulnerability Type
Race Condition
Business Logic Flaw
CWE: CWE-362 (Race Condition)

Description:
The application does not properly handle concurrent (parallel) requests during database user provisioning.
When multiple creation requests are sent in parallel, the backend processes them simultaneously without enforcing serialization, locking, or queuing. This allows multiple database users to be created at the same time, across several backend services.
Although duplicate names are correctly rejected, the system fails to restrict concurrent provisioning, resulting in uncontrolled creation of database users and triggering infrastructure-level actions.

Steps to Reproduce:
Log in to the admin panel.
Initiate database user creation.
Capture the POST request using Burp Suite.
Send multiple parallel requests (race condition).
When duplicate name validation occurs, change the username.
Immediately resend parallel requests.
Observe that multiple database users are created simultaneously.

Actual Behavior:
Multiple database users are created simultaneously.
Backend services execute provisioning tasks in parallel.
No locking or concurrency control is applied.

Impact
An attacker could:
Mass-create database users rapidly
Abuse provisioning workflows
Trigger repeated service restarts
Exhaust system or paid resources

Note: I have attached some pictures and video as a evidence so you can check it…..