Report privately — do not open a public issue.

Use GitHub's private vulnerability reporting: Report a vulnerability. If unavailable, contact the maintainer via their GitHub profile.

Include the affected commit, reproduction steps, and what an attacker gains. First response within 7 days.

This is an archive of L2 coursework, not a deployed product. The issues below matter because the repository is public, so everything in it — including inside the committed .tar archives — is downloadable by anyone.

messagePHP.tar contains the original PHP "Chat One" code before it was cleaned up. Four files inside the archive carry an inline PDO connection:

$bdd = new PDO('mysql:host=localhost;dbname=Message', 'phpmyadmin', 'p');

Because messagePHP.tar is a tracked file in a public repository, the username phpmyadmin and password p are public right now. Removing the archive from a future commit does not help — the current tree, and every commit since the archive was added, contains it.

Current state (September 2026): both archives have been untracked — the files remain on local disk but are no longer in the working tree that will be committed. That stops the credentials being in HEAD. They remain in the git history of every commit before this change, so a history purge is the only way to remove them from future clones.

Recommended next step: the PHP source is preserved, cleaned up, in ProjetGit; the Java source in message.tar exists nowhere else and should be moved to its own repository if it is to be kept at all. Once that is settled, decide whether to purge the archives from history. In the meantime, if a MySQL account phpmyadmin with password p exists on any reachable server, change or drop it.

message.tar is the Java version of the same chat. It connects with jdbc:mysql://localhost/Ma_base; no password matched the scan, so it most likely relies on a blank or default credential — treat it the same way.

index.php → traitement.php → affichage.php / modifier.php store A × 0…A × B in the PHP session. No database, no personal data. The issues are the usual ones for echo-driven student PHP:

• affichage.php echoes $_GET['varA'] straight into the page (row Modifier links). A crafted URL reflects unescaped HTML — reflected XSS.
• The row delete is a plain GET to traitement.php?varA=…&varB=…&varI=… with no session token, so any cross-site <img>/<a> can delete a row the logged-in user is looking at.
• Row indices (varI) and table length (varB) come from the client; two open tabs can delete the wrong row.
• No input validation: A/B are echoed and used as loop bounds unchecked.

Pure client-side HTML/JS. fetch("data.json") loads a catalogue of fabricated book records and innerHTML renders them. data.json contains placeholder authors and ISBNs — treat as demo data, not real people. The book cover images under l2/ are copyrighted scans/covers downloaded for the exercise; they are not this project's to redistribute.

Because everything is in the browser and written back via localStorage + innerHTML, this code is not a model for handling untrusted input: a book record containing <script> would execute when re-rendered. It is a teaching exercise; do not deploy it.

reservation.js and bluediv.js read localStorage and splice values into innerHTML (src=…, card titles). No server. If a value in localStorage ever comes from somewhere untrusted, that is stored XSS — but there is no page in this repository that writes hostile data there.

• No database credentials in the live PHP sources (they use sessions only).
• No real personal data in data.json (fabricated) or in the PHP files.
• No deployed service; nothing here phones home.

The archives are the exception to "no credentials", and they are the one thing worth acting on.

In scope: the archived credentials, reflected XSS / CSRF in the PHP table app, and any real data that turns up in the current tree.

Out of scope: code style, and the client-side design of the Library exercise — it is documented as a teaching piece, not fixed as one.