Undefined behavior is not specified, by definition! It is the absence of requirements, including the requirements to diagnose.
C++ has something called "unspecified behavior" also, which is stronger than undefined, because it gives requirements. It denotes some circumstances when an implementation can behave in one of a finite possible ways (none of which fail) and must choose one of them without documenting which choice is made. For instance the expression f(a(), b(), c()) can call the functions a, b and c in any of the six possible permutations of the order: no particular order is specified. (This arises due to the order of evaluation of function arguments being unspecified, together with the sequenced evaluation of function calls.)
The specifications of C and C++ contain large number of places in which they carefully state that no requirements apply to some situation. This is not a good thing; it's basically a myriad holes punched in the requirement spec, any one of which could be a pitfall.
Few languages are so chock full of holes in their requirements.
But it is precisely specified how to invoke undefined behavior. For example when to numbers are added and they overflow the size of the type. This is carefully specified when this is or isn't undefined behavior. The C++ standard goes into excruciating detail but they have not covered everything
Compare that to many of the newer scripting languages. Elsewhere on this page I described how to recover from a segfault by setting string conversion function, which I don't think was specified anywhere. You can break some newer language by overriding innocuous function like #hash on some objects. These languages have at least as many pitfalls as C++ they are just less well described.
"unspecified behavior" in C++ is a formal term denoting a situation in which requirements are in fact given. There are multiple possible requirements, and the implementation chooses which apply, without having to document the choice. So in fact something is specified, just not entirely.
"undefined behavior" refers to situations in which no requirements apply at all. (Truly unspecified in the regular sense of the word.)
C++ has something called "unspecified behavior" also, which is stronger than undefined, because it gives requirements. It denotes some circumstances when an implementation can behave in one of a finite possible ways (none of which fail) and must choose one of them without documenting which choice is made. For instance the expression f(a(), b(), c()) can call the functions a, b and c in any of the six possible permutations of the order: no particular order is specified. (This arises due to the order of evaluation of function arguments being unspecified, together with the sequenced evaluation of function calls.)
The specifications of C and C++ contain large number of places in which they carefully state that no requirements apply to some situation. This is not a good thing; it's basically a myriad holes punched in the requirement spec, any one of which could be a pitfall.
Few languages are so chock full of holes in their requirements.