News & Events

Security Notice – Risks & Remediation (updated)

calendar_monthMarch 01, 2026

Dear GCIT team,

My name is Matheo (Mathéo) Delbarre from France. I am writing in complete good faith. I have no harmful intentions, no desire to damage anything — only to help, out of respect for your institution and your country. During my exploration of the public-facing endpoints, I documented several configuration risks and wanted to report them responsibly.

1) Executive Summary

Public content API accepts raw HTML and allows creating entries using only a session + CSRF token. Without strict sanitization, this enables potential stored XSS (CWE‑79), which could lead to session hijacking, UI defacement, or actions executed in the context of an administrator.
CORS appears permissive (Access-Control-Allow-Origin: *). Overly permissive CORS policies increase cross-site attack surface. Combined with credentials or insufficient request validation, attackers may perform cross-origin interactions that browsers normally block.
CSRF mechanism relies on exposed XSRF-TOKEN cookies (Laravel pattern). This is normal, but if Origin/Referer validation is missing and CORS is broad, malicious websites could potentially trigger authenticated POSTs.
Uploads accept image files. Currently safe, but if validation ever loosens (extensions, magic bytes, or SVG/HTML allowed), this becomes Unrestricted File Upload (CWE‑434), a historically severe attack vector.

2) What I Tested

Discovered /api/event and confirmed allowed methods through OPTIONS.
Observed permissive CORS responses and CSRF cookie structure.
Created test entries (IDs visible in API). Raw HTML in description is stored and returned. If rendered without sanitization, this becomes stored XSS.

3) Why This Matters (Mapped to Well‑Known Risks)

Stored / DOM XSS (CWE‑79): executing attacker-controlled script inside users’ browsers. Documented extensively by OWASP and PortSwigger.
CORS Misconfiguration: wildcard origins are not recommended for any authenticated endpoint. CORS vulnerabilities are a known source of cross-domain attacks.
Open Redirect class (CWE‑601): any dynamic redirect based on untrusted user input could be abused for phishing or forced navigation.
URL Canonicalization / Path Confusion: malformed or encoded paths may create inconsistent routing across layers.
Unrestricted File Upload (CWE‑434): historically enables stored XSS or even remote code execution if not strictly controlled.

4) Risks to Users & Brand

Phishing & credential theft via malicious script injection.
Unauthorized content insertion damaging institutional image.
Reduced user trust due to potential page breakage or defacement.

5) Recommended Remediations

Sanitize/encode all HTML server-side (default to plain text unless explicitly allowed).
Harden CORS by restricting allowed origins to https://www.gcit.edu.bt only.
Validate Origin/Referer on all state-changing requests.
Implement Content Security Policy with nonces to reduce XSS impact.
Harden uploads (strict MIME, magic bytes, block SVG/HTML).
Normalize/validate URLs before routing or generating redirects.

6) References (Illustrative)

OWASP & PortSwigger — Stored XSS / DOM XSS.
OWASP WSTG — CORS misconfiguration.
CWE‑79, CWE‑434, CWE‑601 — well‑known vulnerability classes.

PS (Personal Note)

I also want to say something personal: I deeply admire Bhutan — its culture, its values, and the national philosophy of happiness. It has been my dream for years to be able to study or work there once my cybersecurity studies are completed. I say this sincerely, because I genuinely respect your country and your college. I am not here to cause any harm — only to help, learn, and contribute where I can.

If you ever wish to contact me, here are my personal links: