The kernel itself is relatively solid, but there are problems.
Interactive services can expose system-level access to users - a design flaw shich should not be allowed. I remember vaguely a hack from the logon of Windows NT which let you use the context menu, then somehow involving 'print' and/or 'help', you could get explorer.exe open without logging in. That was a flaw with the Win32 implementation, but it had to somehow allow user-level access to MSGINA and the kernel system for authentication and security - a good design would have allowed for this. This is Windows NT or 2000, ignoring XP and beyond.
I also remember when Vista moved graphics processing into user mode, so that the usual BSOD from graphics drivers famous in XP would simply be an abnormal termination. Reading suggests this was reversed in 7 because of the slowness this added. If graphics - fundamentally the way the OS communicates with the user, since the command-line is supposed to be a second resort - has to be so close to the metal it can't be in user space without slowing it down, this is not good.
At this point I should say that maybe a command-line interface, under the hood, may be secure. But if the intent is to provide a windowing environment, and the method of doing so is not secure, maybe the kernel has exceeded its usefulness. I should also say that a lot of uninformed people parrot the idea that the kernel is well designed, siply because it flies in the face of all the Microsoft hate. The original nerd hipster, who likes something - or believes that something can be good - even if the masses hate it. Or just because the masses hate it.
I have personally used a Shatter attack to expose passwords masked by asterisks. There is a single byte in the window definition that says "replace every character with this one because this is a password box". If it is not filled in, the text box is normal. If it is filled in, it's a password box. Most apps that display a password set the password style (by default filling that byte with an asterisk) and put the password up. Easy to recover.
If different processes, which should be kept separate from other processes, are vulnerable in this fashion, then either the kernel is wrong or the user layer on top of the kernel is not able to maintain the segragation - in effect the user layer is a vulnerability to the kernel.
Just looking at Vista, and its failure due to UAC and similar security fixes, the fundamental kernel was vulnerable to a number of serious issues - not necessarily with the kernel, but because of its implementation. Having to force an abomination like UAC on programmers so that they would respect security guidelines of least privilage, shows that they did not properly restrict its operation from the beginning - not a flaw in the kernel, but in the overall design. Configured properly, Windows would not run programs, in some cases at all. Configured improperly, it would.
The overhead of creating a fork() in Windows is ridiculous. As a Windows hacker, I found fork() abhorrent - until someone pointed out the difference in overhead.
There are many things wrong with Windows. It is fundamentally sound, but there are a good number of other flaws I won't bore you with, that would probably be more convincing but less headline-tastic. The original conception was a good idea, and it has just gotten worse from there. Perhaps it got worse as knowledgeable people left, and as of 2003 it has stopped getting worse.