Thanks to @cremno for providing a link to the GIT repository for the file in question: kssl.c (Note that this is not the repository head.)

It's clear that this report is spurious. First, there is no real problem with the fprintf call, although you can argue that code in a security-related product like OpenSSL needs to go beyond being secure to the point of being visibly secure even to a casual glance. (I'm not sure I would make that argument, but it has been made.)

But more importantly, the code in question is disabled (note the preprocessor directives surrounding it):

# if 0
{
    int i;
    fprintf(stderr, "%s[at%d:%d] ", label, adata->ad_type, adata->length);
    for (i = 0; i < adata->length; i++) {
        fprintf(stderr, (isprint(adata->contents[i])) ? "%c " : "%02x",
                        adata->contents[i]);
    }
    fprintf(stderr, "\n");
}
# endif

This looks like an automatically generated error message. Obviously the tool doesn't know which format string will be used, so it cannot analyse the format string and the arguments and declare that the usage is safe.

A more clever tool might figure out that there are just two possibilities for the format string, and that each possibility is safe, and not give an error message.

The code itself is safe. Of course you get rid of the message by using an if/else statement. And in safety critical code, you wouldn't just fix things that are wrong, but also things that look wrong. And you never know, after turning the fprintf into an if/else, the tool might detect a real problem that we all missed.

Credit must go to rici, but everything looks ok with the code.

Even there is a problem, everything can be printed safe as char or as hex.

Probably the problem could be with the for or while loop that operates over the string.

Could you post the loop as well?