The Student Assessment System (internally referred to as the Print&Scan application) is a tool for processing multiple choice exams. The inputs for the tool are a file containing user information, a file containing student's answers to the multiple choice exam and and the correct answers. After processing the files, the tool presents the user with some statistics about the exam, as wel as the calculated scores for the students. Each year about 1000 exams are processed using this tool, grading over 50.000 students. Since the results of this tool are used to determine whether students are able to graduate, it is important that it is secure. We challenge you to find the bugs in our Print&Scan tool.

Tier 2
Up to €2,500
Rules of engagement

Types of users

Only logged in users can access the Print&Scan application.
The login is provided by the Identity & Access Management system of KU Leuven.

  • normal users
  • access and modify the exams which are assigned to him (i.e. for which they are a "reporter")
  • can NOT access or modify exams which are not assigned to him
  • can NOT create new exams
  • admin users
  • access and modify all exams
  • create new exams


  • Write your report in Dutch or English.
  • Describe the problem in sufficient detail and include the necessary evidence, such as IP addresses, log entries, screenshots, etc.
  • Provide detailed but to-the-point reproduction steps
  • Include a clear attack scenario; a step by step guide in the PoC is highly appreciated
  • Remember: quality over quantity
  • Only notify the ICTS department of KU Leuven of your findings, and only via this procedure. Do not publish details about the security issue through other channels. Making the problem known through other channels or the media, even before or after notifying the KU Leuven via this procedure and even when not all details are provided, will be considered irresponsible behaviour and can still lead to the filing of criminal charges.
  • Do not exploit the identified leak: only collect the information necessary to demonstrate its existence.
  • Only change or delete data on (if any)
  • Handle any found data in a responsible manner: if you can demonstrate that there is a security problem with a small portion, do not go any further
  • Please do NOT discuss bugs before they are fixed

Our promise

  • If we require additional information, we may choose to contact you, if possible.
  • We will do everything possible to solve any shortcomings as quickly as possible, and we will keep you posted.

Tier 2
In scope


The scope of this project is the Print&Scan tool itself and the Identity & Access Management system which grants access to it.

We are particularly interested in, but not limited to, ways to exploit the tool using:

  • Horizontal or vertical privilege escalation
  • Exploits that facilitate information theft
  • Exploits that facilitate data modification

For the Print&Scan application, the following url (and it's sub paths) is in scope:

The initiation of the login session will redirect you to the Identity & Access Management system, for which only the following domain is in scope:

Vulnerabilities reported for the second url should be logged here.

Out of scope

You will not receive a reward or your submission might be rejected if they are out of scope or if they are one of the following:

  • Highly speculative reports about theoretical damage. Be concrete.
  • Reports that state that software is out of date/vulnerable without proven exploitable risks
  • Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue in the context of our systems
  • XSS issues in non-current browsers (older than 3 versions)
  • Denial of Service Attacks
  • Physical or social engineering attempts (This includes phishing attacks against employees)
  • Missing security headers that do not present an immediate security vulnerability
    Weak SSL configurations and SSL/TLS scan reports (This means output from sites such as SSL Labs) without exploitable proof
  • Banner grabbing issues (figuring out what web server we use, etc.) without exploitable proof
  • Missing source code obfuscation techniques
  • Best practices concerns
  • Missing DMARC/SPF records
  • Dangling subdomains
  • Recently disclosed 0 day vulnerabilities in commercial products where no patch or a recent patch is available. We need time to patch our systems just like everyone else - please give us one month before reporting these types of issues.
  • Missing autocomplete attributes
  • Already known vulnerabilities listed in our issue log
  • User enumeration
  • Information disclosure
  • Stack traces or error pages, for exams you are allowed to access
  • Exploits using Excel macros to attack users
Severity assessment

It will be the responsibility of integriti to pay ethical hackers in a timely and legal way. Payouts will only take place after agreement with KU Leuven on the criticality of the impact and only if the submission was the first of its kind and agreed to be valid.

Examples of exceptional vulnerabilities:

  • Remote code execution
  • Access to the underlying infrastructure

Examples of critical vulnerabilities:

  • Acquire sensitive data of our users
  • Full database access
  • Vertical privilege escalation
  • Access to all user data or access to a targeted user
  • Data loss

Examples of high severity vulnerabilities:

  • Access to data of random users
  • Stored cross-site scripting
  • Impersonation of other user (1 user per time)

Examples of medium severity vulnerabilities:

  • Reflected cross-site scripting with low or no user interaction
  • Stored cross-site scripting that requires a lot of user interaction

Examples of low severity vulnerabilities:

  • Open redirects - 99% of open redirect issues have low security impact. For the rare cases with higher security impact, like stealing sensitive data (customer records...) or introducing XSS, we do still want to hear about them.
  • Self-XSS that cannot be used to exploit other users (this includes having a user paste JavaSript in the browser console)
  • Cross-site request forgery (CSRF) with minimal security implications (logout CSRF etc.) Only create/update and delete actions are interesting.
  • Missing cookie flags on non-security sensitive cookies.

Can we create test accounts?

No, but you can request them using the "Get credentials" button on the intigriti platform.

You should request 2 accounts, because you will get 2 types of accounts:

  • a normal user account
  • an admin account

More information about these accounts can be found in the Miscellany section

How long does it take to fix a vulnerability?

Our goal is to implement a fix as soon as possible. Depending on the criticality and the affected system it can take up to multiple months to implement a fix.

All aboard!
Please log in or sign up on the platform

For obvious reasons we can only allow submissions or applications for our program with a valid intigriti account.

It will only take 2 minutes to create a new one or even less to log in with an existing account, so don't hesitate and let's get started. We would be thrilled to have you as part of our community.

Program specifics
no reputation No collaboration
last contributors
KU Leuven
changed the in scope
KU Leuven
changed the rules of engagement
KU Leuven
closed a submission
KU Leuven
closed a submission
created a submission
KU Leuven
closed a submission
KU Leuven
closed a submission
KU Leuven
closed a submission
KU Leuven
accepted a submission
KU Leuven
closed a submission