Is divide-by-zero a security vulnerability?

At issue is that an exception handler will be invoked to handle the division by zero. In general, attackers know that exception handlers are not as well-tested as regular code flows. Your main logic flow might be sound and thoroughly tested, but an exception handler can be triggered by interrupts occurring anywhere in the code within its scope.

int myFunction(int a, int b, SomeState state) {

    state(UNINITIALIZED);
    try {
        state.something(a/b);
        state(NORMAL);
    }
    catch () {
        state.something(b/a);
        state(INVERTED);
    }
    return retval;
}

This horrible pseudocode sort of illustrates one way the flaw could be exploited. Let's say that an uninitialized state is somehow vulnerable. If this routine is called, the state is first uninitialized. If b is zero, it catches the exception and tries to do some other logic. But if both a and b are zero, it throws again, leaving state uninitialized.

The division by zero itself wasn't the vulnerability, it's the bad code around it that's possible to exploit.

To add another contrived but based on real example:

Many (many) moons ago, my high school was running Novell Netware and had it configured so that students couldn't directly run an dos prompt (which was annoying if you e.g. needed to format a floppy disk). However, it was discovered that if you entered in a password more than X characters (i.e. just held down a key for a while), this would crash netware and drop the system back to ... a dos prompt. Most likely this was a buffer overrun, but the principle is the same: if you're dealing with a system (especially an embedded one) which handles at least some unexpected crashes by dropping you into a maintenance mode, then there is a security concern.

As the other answers are suggesting, it entirely depends on the whole system. That is not just the code, but the platform, language and compiler too.

For example in c++, division by zero on integers is undefined behaviour. One of the rules about that particular language is the compiler may assume that undefined behaviour will never occur, and is allowed to do anything if it does.

Anything includes crash with an error message and clean up, crash without an error message and leave everything in a weird state, or most terrifying try to keep going as if nothing has happened.

Now in practice most good modern compilers try to crash cleanly if they hit something like that, but this should make it clear why the assumption is that it is a vulnerability. If you just build your code with a different compiler or different settings, and don't even change the code, what the program does could go from a clean crash to wiping out your database.