Yes, that is what I was trying to get at in the second paragraph under the "What can I do to help with fuzzing Irssi?…" heading. That there may be certain bugs that require certain non-default configuration options as part of the criteria for triggering the bug.

Even simpler, shouldn't the configuration be part of the fuzzed input?

I actually did do some fuzzing of the config file (just loading Irssi to see if the config file caused a crash) and found a couple of bugs there (for example: https://github.com/irssi/irssi/issues/563). The choice to instead fuzz network traffic as done in the blog post was made, because it is generally more interesting because it is easier for a malicious person to exploit network based bugs than those requiring the user to load a bad config.

But you are right, that the configuration can be part of the fuzzed input. It should be possible to take part of the data fed into Irssi by AFL and use that as the config file and then use the rest as the network traffic.

An attacker who controls the configuration probably can just tell irssi to download his malware and run it.

It might be a good idea to check the parser for bugs but these aren't real security issues.