News

Project 1: Bugfixes and Setup Time Changes

Written on 11.12.25 by Valentin Huber

I was made aware of two distinct bugs with the project setup, and found one cheating avenue, all of which was fixed by a commit that was just pushed to the repositories of all students that have already accepted the project 1 (please run git pull!) — students who have not yet accepted the project will… Read more

I was made aware of two distinct bugs with the project setup, and found one cheating avenue, all of which was fixed by a commit that was just pushed to the repositories of all students that have already accepted the project 1 (please run git pull!) — students who have not yet accepted the project will automatically get the newest version. Here are the changes in detail:

  • Previously, the runtime of any logic run at the top level of fuzzer.py (or any other file imported from there) was not accounted. This means that in principle, students would have been able to use an arbitrary amount of runtime to pre-compute inputs, such that their entire hour of running the target could be spent in the target, even when using a very slow fuzzer. This would obviously be considered cheating. We have changed the behavior as follows: The setup logic is now times. If it takes longer than 5 minutes, any additional time is deducted from your fuzzing budget. Some examples:
    • If your setup logic takes 3 seconds, you will get 60 minutes of fuzzing.
    • If your setup logic takes 4.5 minutes, you will still get 60 minutes of fuzzing.
    • If your setup logic takes 8 (5 + 3 extra) minutes, you will only get 57 (60 - 3) minutes of fuzzing.
  • On Windows systems, git has (as is normal for its operation) converted the line endings of non-binary files to CRLF, instead of the LF used in UNIX, when you cloned the repository. This is done to allow ordinary Windows programs to change the files. The line endings are changed back once the changes are pulled to a UNIX system. However, on a Windows machine, some files (specifically apt-packages.txt and run_and_get_coverage.sh) are simply copied from the Windows host to the Ubuntu Docker image, without the intermediate fixes through git. This lead to failures when trying to build the Docker images on Windows systems, since the extra characters are not legal in those places in Ubuntu. To fix this, the line endings are now manually converted in the Dockerfile.
  • If your fuzzer called some other process that either (a) calls the default system-wide Python interpreter, or (b) is only available as a Python dependency, this would previously fail, because the virtual environment, into which all Python dependencies are installed, was not correctly activated. This should now be fixed.

If you have any questions regarding these changes, please ask them in the forum. I would also like to thank all the students that have reported these bugs and helped me find fixes. Enjoy your fuzzing!

Confusion with the deadline for Assignment 6

Written on 03.12.25 (last change on 05.12.25) by Tural Mammadov

We have just noticed that we made a mistake with the deadline for Assignment 6, specifying December 16th instead of December 9th. To avoid any potential confusion, we will not be changing the deadline for Assignment 6. We will collect your solutions on December 16th. However, we still encourage you to… Read more

We have just noticed that we made a mistake with the deadline for Assignment 6, specifying December 16th instead of December 9th. To avoid any potential confusion, we will not be changing the deadline for Assignment 6. We will collect your solutions on December 16th. However, we still encourage you to complete Assignment 6 this week, as we will release Assignment 7 next week. As usual, you will have 7 days to solve it. So, both solutions for Assignments 6 and 7 will be collected on December 16th. Happy fuzzing!

Project 1 – Scope Adjustment

Written on 19.11.25 (last change on 19.11.25) by Valentin Huber

After some questions and further evaluation by us, we found that project 1 has a shortcut that we deem unfair: If you happened to find a set of very good seed inputs (and there are plenty of those lists out there), you were basically guaranteed to get the maximum grade, even without having to write a… Read more

After some questions and further evaluation by us, we found that project 1 has a shortcut that we deem unfair: If you happened to find a set of very good seed inputs (and there are plenty of those lists out there), you were basically guaranteed to get the maximum grade, even without having to write a fuzzer. We have therefore split the project 1 evaluation into two parts: One with no seeds, and one with a small set of high-quality seeds provided by us. This will provide a more even playing ground for everybody.

For those of you who previously accepted the assignment: I pushed the changes to your repository directly. Please run git pull. For those of you who have not: You will get the updated instructions directly, once you do accept the assignment.

Refer to the README for the updated instructions and rules. Please re-read the entire README, as multiple things have changed. We are sorry about the inconvenience, particularly to students who have already discovered this and put in some work to find good seeds. If you have any questions regarding the new rules, please ask in the forum.

Deadline extension for Assignment 03

Written on 18.11.25 by Alexander Liggesmeyer

We were informed that the deadline for Assignment 03 was shown as 14:00 in the CMS, but the assignment sheet and the announcement in the GitHub classroom stated 12:00. To resolve this inconsistency, we have extended the deadline by one day (19. November at 14:00).

Project 1 Released

Written on 15.11.25 (last change on 18.11.25) by Valentin Huber

All details are available directly in the README of the repository. The deadline is end of the end in CET on 23.12. Find the repository in GitHub classroom.

The preliminary dates for project 2 are: release on 13.01., deadline on 03.03.

Exam dates are specified

Written on 11.11.25 by Tural Mammadov

Dear Students, the exam dates for the "Security Testing" course are now specified:

  • 2026-02-19 Günter Hotz Hörsaal 10:00-12:00 – exam
  • 2026-03-16 Günter Hotz Hörsaal 14:00-16:00 – re-exam

Online notebooks work again

Written on 21.10.25 by Andreas Zeller

Dear all – you can now (again) launch interactive notebooks right out of fuzzingbook.org. Simply select Resources -> Edit as Notebook.

Accessing GitHub Classroom

Written on 21.10.25 by Tural Mammadov

Dear Students,

If you do not find your matriculation number listed on Security Testing GitHub Classroom (for example, you registered later), please reach out to AlexanderTural, or Valentin.

Assignment 00 has been released

Written on 21.10.25 (last change on 21.10.25) by Alexander Liggesmeyer

We’ve just released Assignment 00

You can find it under the Materials section in the CMS:

https://cms.cispa.saarland/fuzzing25/materials/

This initial assignment is meant to get you familiar with the submission process and ensure your setup is ready for the upcoming exercises.

Happy fuzzing!

Show all

Security Testing

The Course. Software has bugs, and catching bugs can involve lots of effort. This course addresses this problem by automating software testing, specifically by generating tests automatically. Recent years have seen the development of novel techniques that have led to dramatic improvements in test generation and software testing.  In this course, we explore these techniques – in theory and in code.

Course Material. The course material comes as a collection of Jupyter Notebooks, in which you can study how the individual techniques work – and even do your own experiments and create new combinations. Every week, you will be getting 1–2 new chapters (notebooks) on a new topic, which we will then discuss the next week in the classroom. All chapters are available at

https://www.fuzzingbook.org/

In the notebook, you can edit the code as you like, run your own experiments, and re-use and extend the code to your liking; but you can also download and use the Python code "as is". Your task will be to use these techniques (and their code) to build a series of fuzzers (i.e., test generators) that find bugs in several challenging settings.

Attending. The lectures for this course take place as an on-site lecture, in which our lecturer (Andreas) will introduce you to the chapters to be read in the upcoming week and answer questions. The book also offers video lectures for each chapter.

Weekly exercises. Every week, you will get an exercise sheet with exercises relating to the current chapter. Your solutions are due after one week and will be graded.

Projects. During the course, you will run two projects in which you will build your own automated fuzzing tools. You will implement projects in Python and use Jupyter Notebooks to document design choices and introduce your readers to the included code.

Exam. There will be an exam at the end of the course:

  • 2026-02-19 Günter Hotz Hörsaal 10:00-12:00 – exam
  • 2026-03-16 Günter Hotz Hörsaal 14:00-16:00 – re-exam

Grading. Grading will be based on

  • points achieved in weekly exercises (25%)
  • points achieved in Project 1 (25%)
  • points achieved in Project 2 (25%)
  • points achieved in the Exam (25%)

To pass, you must achieve 50% of points in each category and 50% of the overall points.

The Prerequisites. We expect programming skills at the level of "Programming 2". Knowledge in Python, program analysis, and instrumentation can be acquired on the go. We use statistics, logic, and machine learning, but nothing too exotic.

Questions and Answers. We will set up discussion forums for questions and answers. You can also ask questions during the lecture and get immediate answers.

Date and Time. Every Tuesday, 14:15–16:00 in CISPA C0, Stuhlsatzenhaus 5, Lecture Hall 0.05. The lecture runs in person. The course starts on Tuesday, October 21. There will be no lectures in the two-week Christmas break; the last lecture is on February 3.

Lecture Plan. (Tentative and subject to change.)

The sequence of chapters is different from the book; to synchronize with the projects, we first discuss black-box techniques, then white-box techniques, and then domain-specific approaches.

2025-10-21: Introduction to the course • Introduction to Software Testing
2025-10-28: Introduction to Fuzzing
2025-11-04: Fuzzing with Grammars • Efficient Grammar Fuzzing
2025-11-11: Grammar Coverage • Reducing Failure-Inducing Inputs (*)
2025-11-18: Probabilistic Grammar Fuzzing (makes use of Parsing Inputs) • Fuzzing with Generators (*)
2025-11-25: Current Trends in Fuzzing Research
2025-12-02: Code Coverage
2025-12-09: Mutation-Based Fuzzing • Greybox Fuzzing • Greybox Fuzzing With Grammars
2025-12-16: Fuzzing with Constraints (with Fandango)
2026-01-06: Fuzzing APIs • Fuzzing Configurations
2026-01-13: Testing Compilers 
2026-01-20: Testing Web Applications
2026-01-27: Testing Graphical User Interfaces
2026-02-03: Mining Input Grammars

(*) Lecture conducted by Tural, Alexander, or Valentin; all others by Andreas

Every lecture discusses last week's topics and teases the new topics (and chapters) listed above, which you are to study in the following days. On 2025-11-04, for instance, we tease the chapters "Fuzzing with Grammars" and "Efficient Grammar Fuzzing." You are then to study them by the lecture the week after, in which we will discuss your thoughts and experiences. Lectures come with live coding, so we can explore ideas right on the go.

More questions? Come and meet us in the lecture hall!

Enjoy! – Andreas + Tural + Alexander + Valentin

Privacy Policy | Legal Notice
If you encounter technical problems, please contact the administrators.