Recent events
A global theme on the kde third party store had an issue where it executed a script that removed user's data. It wasn't intended as malicious, but a mistake in some shell parsing. It was promptly identified and removed, but not before doing some damage to that user.
This has started a lot of discourse around the concept of the store, secuirty and upstream KDE. With the main question how can a theme have access to do this?
To developers it's not a surprise that third party plugins can do this sort of thing. It's as intended. A global theme can ship custom lockscreens, custom applets, custom settings and all of these can run arbitrary bundled code. You can't constrain this without limiting functionality.
To that end there's an explicit warning when downloading plugins.
Expectations
Our primary issue boils down to expectation management and communication.
There are plenty of other ways where users can download and run any other unfettered code from the internet; the Arch user repository (AUR), adding ubuntu PPAs and alike. This isn't a bad thing - it's useful and people do amazing things with this to benefit users.
Nothing on the KDE store happens without explicit user interaction either.
A problem is there's an expectation that because it's programs that it's inherently unsafe and a user needs to trust the source. Our issue is phrases like "global themes" or "Plasma applets" don't always carry this message.
The tech world has changed a lot over the past decade and whilst our code hasn't changed, users expectations have. More and more places provide well kept walled gardens where most actions accessible via the UI are safe-by-default - or at least claim to be!
I've also seen confusion that because a lot of our UI is written in a higher-level language (QML) that's enriched with javascript all browser sandboxing automatically applies. Even though that's not what we claim.
But ultimately if there is a gap in expectations, that's on us to fix.
What can we do better?
In the short term we need to communicate clearly what security expectations Plasma users should have for extensions they download into their desktops. Applets, scripts and services, being programs, are easily recognised as potential risks. It's harder to recognise that Plasma themes, wallpaper plugins and kwin scripts are not just passive artwork and data, but may potentially also include scripts that can have unintended or malicious consequences.
We need to improve the balance of accessing third party content that allows creators to share and have users to get this content easily, with enough speed-bumps and checks that everyone knows what risks are involved.
(UI from Flathub for potentially unsafe content)
Longer term we need to progress on two avenues. We need to make sure we separate the "safe" content, where it is just metadata and content, from the "unsafe" content with scriptable content.
Then we can look at providing curation and auditing as part of the store process in combination with slowly improving sandbox support.
Do I need to do anything as a user?
If you install content from the store, I would advise checking it locally or looking for reviews from trusted sources.
If you're a sys-admin you might want to consider adding the following to block users installing addons with the following kiosk snippet.
/etc/xdg/kdeglobals
[KDE Action Restrictions][$i]
ghns=false