The Ministry Forgot It Twice

Campaign Statistics

A sweep of the Democratic Republic of Congo's government digital surface -- public git repositories associated with .gouv.cd domains -- produced the following results. All data was retrieved from repositories that required no authentication.

The Same File, Two Repos

The Democratic Republic of Congo's Ministry of Higher Education, University Studies, Scientific Research and Technological Innovations -- MINESURSI -- operates its official web presence from a cPanel shared hosting environment on minesursi.gouv.cd. Its production configuration file, config/config.php, contains the database host, database name, and database password for the ministry's MySQL instance. That file is committed to the ministry's public git repository and clones without authentication.

The same file, with the same database credentials, appears in a second repository: principal.minesursi.gouv.cd, a separate frontend subdomain run under the same ministry. Two different subdomains. Two different git repositories. The same hardcoded password in both.

A deployment script committed alongside the credentials in the principal repo -- deploy-email-config.sh -- contains the cPanel username for the ministry's production hosting account and the expected file path on the server. This fingerprints the hosting environment completely: the server, the account, and the directory layout, all from a committed shell script intended to be run locally.

No exploit was used. No credentials were brute-forced. No firewall was bypassed. The repositories at minesursi.gouv.cd and principal.minesursi.gouv.cd cloned without authentication and returned working-tree content including production configuration files with plaintext database credentials. The deployment script committed alongside them maps the production hosting account.

The App Password Problem

Under MINESURSI's technical umbrella sits DANTIC-ONE -- a digital solidarity and mutual support fund platform running on a database called solidariteone. DANTIC-ONE's .env file is committed to its public git repository. That file contains an SMTP configuration pointing to Gmail, with a 16-character Google App Password for [email protected].

A Google App Password is a credential generated specifically by Google to allow an application to authenticate with Gmail when the account has two-factor authentication enabled. It bypasses the normal login flow and authenticates directly to Google's SMTP infrastructure. The one committed in DANTIC's repository grants full SMTP send access to this Gmail account from any network.

The same .env file, with the same Gmail App Password, appears in a fourth repository: danticmutuel.minesursi.gouv.cd, a mutual fund variant of the same platform. The password was committed in two repos. The database root password in the same files is blank -- no password at all on the solidariteone database root account.

Why This Matters

The Democratic Republic of Congo is the largest country in sub-Saharan Africa by area and the largest Francophone country by population. MINESURSI administers a higher education sector spanning dozens of public universities. Its digital infrastructure -- the official government website, its public-facing frontend, and ministry-affiliated fund platforms -- all committed credentials to repositories accessible without authentication.

The ministry's database credentials expose the backend of both the main website and its principal frontend to anyone who reads the config files. The cPanel deployment script narrows the picture further: it identifies the hosting provider account and the exact file path where email configuration would be deployed, information that maps the production server environment from a committed shell script.

The Gmail App Password represents a different category of exposure. App passwords generated by Google do not expire automatically. They remain valid until explicitly revoked in the account's Google Security settings. A 16-character app password committed to a public git repository -- even if the commit is later deleted from the branch -- remains in git history and is recoverable from any prior clone of the repository.

Targets Audited

Ministry of Higher Education and Research (MINESURSI)

Ministry of Environment (MEDD)

Enumerated / Bare Repositories

Critical Findings

The APP_ENV Problem

Both MINESURSI config files carry define('APP_ENV', 'development') -- the application environment flag is set to development mode in the live production configuration. This is not a sandbox or staging deployment: the files use the live database host (localhost) with a non-default database name (minesu_publica) and a non-default username (minesu_user). In PHP frameworks that respect this flag, development mode typically disables error suppression and enables verbose output, meaning the production site may be surfacing internal error details to visitors. The flag also signals a configuration file that was written for development and promoted to production without revision.

The DANTIC system carries the same pattern in the opposite direction: APP_BASE_URL=http://localhost/solidariteone/public -- a localhost URL in a deployed application. This indicates the application was configured on a development machine and the .env was pushed to version control without being updated for the production environment.

The Duplication Pattern

What distinguishes the DRC findings from a straightforward credential exposure is the repetition. The MINESURSI database password appears in two different git repositories -- not because the ministry runs two different databases, but because a second subdomain with a second repository was set up using the same configuration files. The DANTIC Gmail App Password appears in two repositories for the same reason: a mutual fund variant was created by forking the base repository and deploying it as a separate subdomain, .env file included.

This means that patching one repository -- deleting the credential file from the tip of the branch -- leaves the credential exposed in the second repository and, in both cases, in the git history of both. Four separate remediation actions are required to close the exposure.

Raw Data and Downloads

What This Means

Two patterns explain the DRC exposure. The first is credential copy-paste: a config file containing production credentials was duplicated into a second repository without being sanitized. The second is .env-in-version-control: a Laravel-style environment file containing live SMTP credentials was committed to git and pushed to a public remote. Both patterns are common. Both were repeated here.

• The MINESURSI database credentials expose the ministry website backend to any network. The database host is localhost -- the credentials are for the application's own database on the hosting server, accessible via the hosting account or through the application. Anyone who holds the credentials and can reach the hosting environment can authenticate to the database directly.
• The cPanel account fingerprint in deploy-email-config.sh narrows the attack surface. Knowing the hosting username (d10681) and the expected path structure on the server is information useful for targeting other applications or accounts that share the same hosting environment.
• The Gmail App Password is a durable credential that survives git history. Deleting the .env from the current commit does not remove it from prior commits or from clones already made. The password must be explicitly revoked in the Google account's security settings, not just removed from the repository.
• The blank database root password on the solidariteone database represents an authentication bypass. Any process on the host that can connect to MySQL on 127.0.0.1 can authenticate as root with no password.

Immediate remediation steps: For MINESURSI -- rotate the minesu_user database password on minesu_publica; run git-filter-repo to purge config/config.php from the commit history of both repositories; set APP_ENV=production; remove deploy-email-config.sh from the principal repository and purge it from history. For DANTIC -- revoke the Gmail App Password immediately via Google Security settings; set a non-blank MySQL root password on the solidariteone database; run git-filter-repo to purge .env from both the dantic.minesursi.gouv.cd and danticmutuel.minesursi.gouv.cd repositories; update APP_BASE_URL to the production URL before any future deployment.