I don't believe we've seen anything similar. But, of course, it could be that you are the only person to have spotted it.
I doubt they would do anything and would simply say that it is something to do with your configuration. There are many ways to mess up the security of AWS. For example, if you are using S3 storage, there are all too many people who end up leaving it unsecured.
I would suggest that if you are using Docker containers on AWS, you should rebuild the container from scratch on a clean machine. Take everything you can off AWS, go through all your AWS settings and make sure everything is locked down. Then reset any logins and change passwords. Finally put the clean container back in place.
A compromised dependency would not need to edit the Node-RED flow, it would just do all this from within it's own code and not expose it's self to being discovered like this.
The fact the flow was edited very much indicates that something/someone had access to the Node-RED instances API to inject these tabs. As others have mentioned there are bots scanning for access to unsecured Node-RED instances, they normally install crypto-miners (which given the CPU counting sounds like that was the intention)
The other reason I say this is because anything just editing the flow file on disk wouldn't actually be run unless they also restarted the Node-RED process (or issued an API call) to trigger reloading the flow file. Making the changes via the API causes the code to be running straight away.
My opinion is that the Node-RED instance was actually exposed to the internet some how. If IPv4 is all locked down (behind a NAT gateway and no port forwarding and VPN only access) then it could be IPv6, if your network is IPv6 enabled and you don't have default firewall rules blocking incoming traffic that would be my first guess. Lots of routers still come with no IPv6 Firewall enabled.
Normally the IPv6 address range is too large to scan, but it may be that attackers have found ways to narrow the search.