Unblockable instant message spam
tracked
Bumping Pixels
There is an exploit that currently allows spamming users with llInstantMessage, it is not able to be blocked, and is relatively easy to perform. This is an issue I am seeing in increasing frequency, and since all existing tools are failing residents they're faced with the reality of accepting the unavoidable spam, or just disabling offline IM emails and logging out.
I am sharing the details of the exploit privately with Linden Lab, so I ask anyone reviewing this to please not discuss details or steps of the exploit in the comments or in public view to limit the spread of knowledge to utilize this exploit. It is already under active use by spammers, but not everyone knows about this and they don't need to until some sort of remedy is identified.
From the perspective of a viewer developer this is relatively trivial to solve for users of one specific viewer, but an issue of this nature and scale deserves a direct resolution at the source for all residents, perhaps a new way to block, or some new flavor of server side protections. Details up to LL to determine, now that the issue has been raised and awareness exists.
Log In
Spooky Pumpkins
As I mentioned in the CCUG - this issue has been ongoing for a long time.
I personally started filing abuse reports in NOVEMBER of 2023 about this. I have many social media posts venting about it with screen shots.
I made a support case last year asking to assist with this - was told to just file an abuse report and make a canny post. So I created a canny post as I was instructed to and I've filed an abuse report after abuse report trying to bring attention to this exploit.
If someone is genuinely being stalked and harassed by another user, this exploit can be heavily abused and make the user leave SecondLife completely just to avoid their stalker/harasser. (worse than the L$1 message spam that they can do after being blocked).
This cannot continue to go unaddressed. It's been a minimum of 18 months (that I personally have been bringing this up to the Lab in various methods) since this issue was brought to the Lab's attention.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Blau Rascon
Spidey Linden excellent use of the boilerplate on this one
Spidey Linden
under review
Bumping Pixels
I'm sorry but the handling of this issue by Maestro was just disappointingly unprofessional, and plain unsafe.
I specifically requested the details of this exploit be kept confidential as to not advertise it more widely to would-be abusers, and that directive was just patently ignored and trampled over.
If this is the attitude of Linden Lab toward issues that impact residents day to day usage of the platform negatively and leave us with NO recourse, I don't really know what to say. It was an easy request; just don't disclose the details. SMH
AlettaMondragon Resident
Bumping Pixels They used to do better than this but since last October this seems to be the new standard. It is very disappointing.
Maestro Linden
open
Moving this to feature requests, since the request here is expanded IM-blocking support, particularly around group-owned objects.
Maestro Linden
needs info
Maestro Linden
Hi Bumping Pixels, I tried this out with Second Life Release 7.1.14.15192634334 on Second Life Server 2025-04-24.14648572313, and it's generally working for me:
- UserA: rez 2 objects and place the LSL script below into both of them
- UserA: deed both objects to group GroupG
- UserB (who is configured to receive offline IMs in email): touch both objects, and observe that 'spam' messages come from both of them
- UserB: click the 'i' icon next to the objects' name in chat, and select 'Block' for each of them
- UserB: observe that messages are not received
- UserB: log out
- UserA: send UserB an IM
- UserB: observe that UserA's IM appears in your email inbox, but not the blocked objects' IMs
- UserB: log in, and note which messages you see
Expected results:
- UserB shouldn't see any IMs from the blocked objects after they are blocked in step (4).
Actual results:
- UserB's muting of the objects generally works - no messages are see immediately after muting them, or when UserB is offline.
- However, UserB sees a single IM from each object after login at step (9). This appears to be a race condition with the viewer fetching the block/mute list and receiving the IMs from the objects.
I think the viewer displaying the single message from a blocked object at login time is a valid viewer bug, and I don't see any open issues for it currently. But I also see that behavior when the object is owned by an agent, so it appears unrelated to group-deeding.
In your repro steps, you don't mention whether the target agents blocked the spamming object. Can you clarify if this step was taken?
Alternatively, is your complaint that there is no way to block/mute all objects owned by a particular group, whereas you can block all objects owned by a given agent?
key target;
default
{
state_entry()
{
llSetObjectName("Spammer " + (string)llFloor(llFrand(100)));
llSay(0, "My key is " + (string)llGetKey());
}
touch_start(integer total_number)
{
llSay(0, "Spamming " + llDetectedName(0));
target = llDetectedKey(0);
llSetTimerEvent(2);
}
timer()
{
llInstantMessage(target, "spam " + llGetTimestamp());
}
}
Bumping Pixels
Maestro Linden Yes, the step was taken, but crucially the step you are missing from my steps is that scripted agents / spammers create NEW groups EVERY TIME they want to send a wave of spam, they do not use the same group more than once.
When you block a sender, it blocks their ID only, not the last owner, not the creator, the owner itself and that's it. Rolling into a new throwaway group each time allows this block to be bypassed rendering this approach "unblockable" in practice due to being a blind spot to long-standing abuse control mechanisms.
Yes, as crazy as it sounds attackers are repeatedly burning L$100 to change the owner ID of the object without having to make new accounts so they can bypass your registration abuse detection. You can check this yourself, here's an example of the recent attack that motivated this report.
If reviewing logs, this may help you narrow things down.
[2025/05/28 13:25:27] SLT
Maestro Linden
My understanding is that this is a feature request to have a block method which will block messages from objects at were either (1) previously owned by a particular agent or (2) created by a particular agent, correct?
AlettaMondragon Resident
Maestro Linden Bumping also asked to keep the details of this exploit away from this public platform, so that spammers that don't know how to do this still won't. At least I know I can't put my exploit report here at all, not even without the specific details. Sadly there is no secure channel to get these issues to your team. It looks like the one I filed at Support never reached you. Is there any proper channel to bring bugs with sensitive and abusive details to your attention?
Maestro Linden
AlettaMondragon Resident: Filing a support ticket is the correct way. Do you have the ticket ID (7 digit number) of that support ticket handy?
AlettaMondragon Resident
Maestro Linden I've just sent it to you in IM inworld.
Bumping Pixels
Maestro Linden I'd honestly just propose that group deeded objects only be able to llInstantMessage group members, and otherwise at the most only child agents of the region it's in.
But as a more manageable suggestion; when you block a group, maybe block the founder as well automatically and whenever the viewer gets a group deeded object IM check that group founder as well as the group ID itself against the block list.
Bumping Pixels
AlettaMondragon Resident FWIW, if you file a bug report on here, and use the lower two fields, those details are NOT shown to the public. This report is a great example, notice how Maestro was asking me specific details about steps I provided, but you cannot see the steps on the issue itself.
Regardless I'd use whatever method you are more comfortable with, and what Linden Lab themselves suggest, but I wanted to point that out to you in the case it wasn't apparent.
A downside of this is that the information in those fields cannot be seen by ME either, after submitting the feedback. There's no real indicator given that the fields will be kept private, or who can see them and when. Could be better labeled.
AlettaMondragon Resident
Bumping Pixels OH! That's very useful info, thank you! I did think those fields were simply dead, judging by the fact their contents didn't show after submitting, when I used them once. It can be useful in such cases indeed, I can't say I think it's convenient, if Maestro eventually gets to the one I've filed a month ago at Support that's good enough for me.