I can reproduce this.

Operating System: Solus 4.5
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.3
Kernel Version: 6.6.22-281.current (64-bit)
Graphics Platform: X11
Processors: 16 × 11th Gen Intel® Core™ i7-11800H @ 2.30GHz
Memory: 62.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
Manufacturer: Dell Inc.
Product Name: XPS 17 9710

Another thing that seems related - once on a locked screen, if I press Esc key, it goes to blank/black screen, where nothing is shown, not even a cursor. Pressing Esc once more goes back to lockscreen. Esc used to defocus out of the "enter password" dialog, now it does this. Definitely not a feature as not even a background is shown.

(In reply to Daniel Duris from comment #2)
> Another thing that seems related - once on a locked screen, if I press Esc
> key, it goes to blank/black screen, where nothing is shown, not even a
> cursor. Pressing Esc once more goes back to lockscreen. Esc used to defocus
> out of the "enter password" dialog, now it does this. Definitely not a
> feature as not even a background is shown.

It's not a bug. Pressing Esc when the screen is locked simply turns it off/on.

This seems to be fixed in the latest KDE.

Operating System: KDE neon 6.0
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

Nope, unfortunately, the flash of unlocked content has happened again.

I can also confirm this bug. It happens every time I wake the computer from sleep.
Has been like this for the last couple of months now. 
However, if I invoke the lock screen (Meta-L) before putting the computer to sleep, it does not happen.

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.6.46-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-3520M CPU @ 2.90GHz
Graphics Processor: Mesa Intel® HD Graphics 4000
Manufacturer: LENOVO
Product Name: 2356FE6
System Version: ThinkPad T430s

I've noticed that on my system, I don't see this bug with Wayland. I only see it with X11.

*** Bug 492735 has been marked as a duplicate of this bug. ***

(In reply to cwo from comment #8)
> *** Bug 492735 has been marked as a duplicate of this bug. ***

Thanks!  I did look for duplicates, but apparently my method was flawed. Looking back at my url history, it seems that by default, https://bugs.kde.org/query.cgi adds my email address in the "Search By People" section, which isn't even expanded unless I happen to click on it, so I had no idea I was only looking for bugs I already had some involvement with.

But one thing this bug hasn't mentioned, which my duplicate bug did, is the wording of the settings.  If indeed the desired behavior is for it to lock before sleeping, then why does it say lock after waking up?

According to MrAnderson in comment 6, it doesn't happen when he manually locks the screen before sleeping, which would seem to indicate it's only locking after waking up.  But that seems contrary to what Martin Flöser said in bug 388384: "The screen is supposed to be locked before going to suspend. In fact the lock screen ensures that suspending gets delayed till the screen is locked."

*** Bug 498003 has been marked as a duplicate of this bug. ***

It's a race. The screenlocker is supposed to start before suspend, but it gets frozen before it has time to draw over the desktop. This has been going on for over a decade (https://bugs.kde.org/show_bug.cgi?id=316734), and apparently nobody is interested in fixing it because "it works on wayland".

The easiest workaround is to add a short sleep during the suspend/hibernate process (e.g. in /etc/[e]logind/system-sleep/foo) so that the screenlocker has time to actually draw a frame before PM freezes tasks.

*** Bug 500498 has been marked as a duplicate of this bug. ***

Well, the "works on Wayland" is relative. I did notice it happening also there, just way quicker than in Xorg and not always, therefore probably not looking as bad an issue, but still existing.

I found on the settings an option called "Lock after waking from sleep". I don't know if it's related, but this makes me thing that the locking is happening, as the option says, after waking up, and during the time between waking up and locking, the desktop is shown.

If I lock the screen first, and then put the computer to sleep, when I wake it up, it behaves 100% correctly, both on Xorg and Wayland. Which makes me think the screen locking should happen **before** going to sleep.

I'd like to remark that this can represent a major privacy and security issue for some people when using computers in shared environments and should be addressed, even if we're moving on to Wayland. Unfortunately I don't have the technical ability to fix this myself, otherwise I'd volunteer. Hope to see somebody step up soon, as this seems to have been a problem for quite a few releases already.

I tested this on Wayland on git-master, as well as Plasma 6.3.2 and was unable to reproduce
"Lock after waking from sleep" was enabled

1. Put the system to sleep
2. Wake the system

I saw nothing but the login screen, no flash of anything on the desktop

If it's really a race, as Steve Vialle indicates, then one's inability to reproduce is of no consequence; only one's ability to reproduce would be of consequence.  The only indication that it has indeed been fixed is to point to code that was changed.  While Steve Vialle's workaround is a help to those who experience the problem the most, it isn't ultimately a way of fixing things.  What we need is a guarantee that the screen has in fact been redrawn/repainted, and only then sleep the system.

per comment 13:
> I did notice it happening also there, just way quicker than in Xorg and not always, therefore probably not looking as bad an issue, but still existing.

That's consistent with a race condition.   As for "not looking as bad" on Wayland, that is of course relative.  Anyone actively exploiting this security/privacy bug could use a camera and then take as much time as he likes to read the screen.  And, given this report, the bug's current title "On X11, ..." and keyword "X11-only" are wrong and should be changed.

And of course, once fixed, the wording of the settings should be changed from "Lock after waking" to "Lock before sleeping".

(In reply to kbtr.buffer098 from comment #13)
> the screen locking should happen **before** going to sleep.
Of course it should, that's the only way to ensure that, in the (very likely) event GPU memory is restored before the relevant KDE process(es) are thawed, said memory doesn't contain an image of the unlocked desktop.


(In reply to kdebugs from comment #15)
> The only indication that it has indeed been fixed is to point
> to code that was changed.
AIUI, the "indication" is a callback from kwaylandserver to say the screenlocker window has been mapped... Not that the framebuffer has actually been updated mind, just that the screenlocker has a window. If that is indeed how it (currently) works, then it's still going to be racy, just less so. 
On X11 we don't even have that much, as far as I can see it's just "fire and hope".

Personally I doubt this will ever be fixed, Nate's comment from the bug I linked (which, IMO, should never have been closed as this was never *properly* addressed) kinda says it all WRT interest:
"if you want a better experience here, use Wayland."

Why there is so much resistance to implementing even the bare-minimum workaround I don't know. While certainly not ideal, surely a sub-second delay before calling suspend is still preferable to this rather obvious security flaw.