Assignment 1 - CVE Brief

Description

This assignment focuses on researching a popular software product and analysing one recently published vulnerability (CVE) affecting that product. Each group presents its findings to the class, including a working demonstration of the vulnerability.

By completing this assignment you should be able to:

• Read and interpret CVE records, vendor advisories, CVSS scores and patch information;
• Assess the real impact of a vulnerability and whether it is being actively exploited;
• Reproduce a known vulnerability in an isolated laboratory environment;
• Communicate security findings clearly and concisely.

Presentation content

The presentation must take at most 15 minutes per group (12 minutes of presentation plus 3 minutes for questions) and cover the following:

• The product: what it is, what it does, and the use cases where it is present. You should be able to answer: who deploys it, and which data or systems would be at stake if it were compromised?
• The security record: how many vulnerabilities were published for the product in the last 3 years, which types/CWE classes they fall into, the trend over time, how promptly the vendor patches, and the product’s overall reputation. All numbers must cite their source.
• The selected CVE: what the vulnerability is and where it lies in the code, its affected versions and CVSS score (with the rationale for the score), how it was reported and by whom, how it was fixed and how long the disclosure took, whether it was exploited in the wild, and the overall impact. Relate the vulnerability to a CWE class and to a topic covered in the lectures.
• A demonstration: a demonstration of the vulnerability, demonstrating its impact on a system or on data. The demonstration is mandatory and is graded as one of the criteria below.

Rules

Groups

Groups are composed of 2 to 3 students. Reservations and submissions must list the full names and student numbers of all members. The grade is shared by the whole group; individual grades will only differ in case of unjustified absence on the presentation day.

Uniqueness

Each group must select a distinct product and a distinct CVE. No two groups may work on the same product, even with a different CVE. Reservations are processed on a first-come, first-served basis, using the timestamp of the message posted in the reservation channel. Staff will ask the second group to pick a new product/CVE. If you discover, after reserving, that another group posted the same product/CVE before you, you must change your selection.

Selecting the CVE

• The CVE must have been published on or after 1 November last year. The date is measured on the NVD/CVE Program Published field, not on the disclosure date, the advisory date, nor the Last Modified field.
• The CVE must already be public at the moment you reserve it.
• The CVE must exist in the CVE Program/NVD and must not be REJECTED or disputed.
• There must be enough public information to analyse it: a vendor advisory or equivalent write-up describing the root cause and the fix.
• The vulnerability must be demonstrable in a lab environment you can build yourself.
• Impact bar: the CVE must either have a CVSS score of 7.0 or above, or be listed in the CISA KEV catalogue, or have documented exploitation in the wild. If none applies, the group must justify the relevance of the choice, and staff may reject it.

Selecting the product

“Popular” means the product must be:

• Publicly maintained, with a public security advisory channel (or a documented patch process);
• Present in public vulnerability aggregators with a meaningful history (as a rule of thumb, at least 20 published CVEs in the last 3 years);
• Runnable in a virtual machine or container so that a demonstration can be built.

Examples of admissible products: widely deployed web applications and servers, mail servers, CMSs, network appliances and device firmware, widely used open-source libraries and frameworks, industrial/SCADA software with public advisories. Examples of inadmissible selections: products with no public advisories; hyperscale SaaS platforms you cannot install; selections where the only available information is a news article.

Rules of engagement

Only attack systems that you own or have explicit permission to test. Demonstrations must run entirely in your own virtual machines or containers. Testing against production systems, university infrastructure, or any third-party system is forbidden and may constitute a crime. Do not analyse or present vulnerabilities that are still unpatched and unknown to the vendor, and keep exploit code out of public repositories (GitHub repositories must be private).

Academic integrity

All material must be original. Sources must be cited on the slides, including any public exploit, tool, advisory, blog post or figure you use. Public exploits may be used and are encouraged, as long as their authors are credited and you are able to explain what the exploit does line by line. Generative AI tools may be used for support (language, exploration of sources) but you are responsible for the correctness of everything you present, and must be prepared to answer technical questions about it individually.

Language

Slides must be in English. Presentations may be given in Portuguese or English, with English mandatory if there are non-Portuguese speakers present.

Deliverables and key dates

Deliverables checklist:

1. Slides, submitted as a single PDF file named AEV-A1-Group<NN>-<short-product-name>.pdf by one member of the group, on E-learning. Maximum of 20 content slides (excluding title and references).
2. Optional supporting material for the demonstration: the environment description (e.g. a docker-compose.yml or VM snapshot instructions), uploaded with the slides, so that staff can reproduce it.
3. A references slide listing every source used, including exploits and images.

Late submissions are penalised 10% per day or fraction. Not presenting without a justified absence is graded 0.

Grading

The assignment contributes 1 points over the 20-point final grade (see the course grading table), and is graded per group, according to the following rubric.

How to reserve a product and CVE

Post a single message in the reservation channel using the template below, and edit it only if staff asks you to. The pinned reservation list is the authoritative record of what has been taken; check it before choosing.

[A1] Group: <full names + student numbers>
     Product: <product and version/branch analysed>
     CVE:     <CVE-YYYY-NNNNN>
     Env:     <docker | VM | vulhub | other>

Getting started

1. Pick a product you already use or recognise, and check its CVE history on CVE Details or the vendor’s advisory page.
2. Shortlist recent CVEs, filter by the date and impact rules above, and confirm that a public advisory and, ideally, a public exploit exist.
3. Stand up the vulnerable version in a lab environment (see the lab environments below), reserve the pair, and only then start writing the slides.

Relevant Links

Databases and aggregators

• NVD - National Vulnerability Database: https://nvd.nist.gov - the authoritative record, with the Published date used by this assignment.
• CVE Program: https://www.cve.org - the official CVE list and numbering authorities.
• CVE Details: https://www.cvedetails.com - best interface to explore the history and product statistics of a product.
• Vulners: https://vulners.com - aggregated vulnerability intelligence and related exploits.
• OSV: https://osv.dev - vulnerability database for open-source packages.

Known exploitation and scoring

• CISA KEV - Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog - evidence of real-world exploitation.
• CVSS (FIRST): https://www.first.org/cvss/ - scoring specification and calculators (v3.1 and v4.0).
• EPSS: https://www.first.org/epss/ - likelihood of exploitation, useful to argue relevance.

Advisories and disclosure timelines

• GitHub Security Advisories (GHSA): https://github.com/advisories - advisories for open-source projects, usually with the fixing commit.
• Exploit Database: https://www.exploit-db.com - historical archive of public exploits.
• SecurityFocus BugTraq: https://www.securityfocus.com - long-running archive of vendor advisories.
• Packet Storm: https://packetstormsecurity.com - advisories, tools and exploits.
• Rapid7 Vulnerability Database: https://www.rapid7.com/db/vulnerabilities - analysis and detection content.

Lab environments

• CVE Sandbox: https://github.com/afonsovitorio/cve_sandbox - platform to research, develop and test CVEs in isolated environments.
• Vulhub: https://github.com/vulhub/vulhub - ready-made Docker compositions of vulnerable applications, ideal for the demonstration.
• VulnHub: https://vulnhub.com - downloadable vulnerable virtual machines.

News and write-ups

• The Hacker News: https://thehackernews.com
• BleepingComputer: https://www.bleepingcomputer.com
• Project Discovery / Nuclei templates: https://github.com/projectdiscovery/nuclei-templates - concrete test cases and PoCs.

FAQ

Can two groups pick the same product with a different CVE? No. Both the product and the CVE must be unique.

Is the demonstration mandatory? Yes, and it accounts for 25% of the grade. If a live demonstration fails, show the recorded fallback (see Presentation content).

Can we use a public exploit? Yes, as long as you credit the author and can explain what it does.

The CVE was disclosed in 2025 but published in January 2026. Which date counts? The NVD Published date, which in this case makes it admissible.

Can we present a 0-day we found ourselves? No. Only already published, vendor-acknowledged vulnerabilities may be analysed.