Server Bugs

Selecting a physical vehicle that another resident is driving — by entering edit mode (Ctrl-3) and clicking it, or by right-clicking it so the context menu opens — stops the vehicle dead for as long as the selection is held. The selecting avatar needs no permissions on the object: not owner, not group, no modify rights. On deselect the vehicle resumes from zero velocity. This is being used (accidentally and otherwise) to disrupt organized racing: a spectator right-clicking a passing car to inspect it halts that car mid-lap. The same behavior was reported as SVC-34 ("Right-clicking another Resident's moving object freezes it") and listed as fixed in server release 11.09.23.241511, alongside "Anybody can freeze an unscripted physical object." The edit-mode selection path still reproduces in 2026. Linden Lab's own QA test script acknowledges it — Object Selection Test, "Select other's vehicles": "verify you can select other's vehicles and their vehicle stops. Unfortunate." (page last edited October 2013). No script-side mitigation exists: STATUS_BLOCK_GRAB does not affect selection (and the same test page notes it doesn't work anyway), the Locked checkbox only restricts the owner, and disabling Build on the parcel does not block selection. ## Steps to reproduce Avatar A rezzes any physical scripted vehicle (a Linden Vehicle Tutorial car is sufficient), sits, and drives it in a straight line at steady speed. Avatar B, who does not own the vehicle and has no modify rights, presses Ctrl-3 to enter edit mode and clicks the moving vehicle. Observe: the vehicle stops immediately and stays stopped while B holds the selection. B presses Esc to deselect. Observe: the vehicle resumes from zero and re-accelerates. Repeat with B right-clicking the vehicle instead of using Ctrl-3. Observe the same stop while the context menu is open. ## Expected behavior Selecting an object you cannot modify should not alter its simulation. Physics should only be suspended for a selection by an agent who has modify rights on the object (owner, or group with appropriate permissions), and ideally only when that agent begins an edit operation. ## Actual behavior Physics is suspended for any selection, regardless of the selecting agent's permissions on the object. ## Environment Region: [fill in region name and server version from Help > About] Viewer: [fill in viewer and version — reproduces with Second Life Viewer and Firestorm] Date observed: [fill in] ## References Object Selection Test (SL Wiki, LL QA test script): https://wiki.secondlife.com/wiki/Object_Selection_Test Server release notes 11.09.23.241511 listing SVC-34 as fixed: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/11

Land deeded to group not working for the owner. Owner is not allowed to place objects on the land or use the controls of the parcel. Also, the group the land is deed on cannot be controlled by the owner creator of the group. It is not allowing for the owner to invite members, give tags to members, or create new notices for the group. Location of problem: https://maps.secondlife.com/secondlife/Cedar%20Point/32/60/40

In a previous server version, llGetAnimation() would never return "Standing" while a pushed avatar was still moving, unless stuck against a wall. But now it does. To reproduce, put this script in an attachment: default { state_entry() { llSetTimerEvent(0.2); } timer() { llSetVelocity(<14, 0, 0>, TRUE); llOwnerSay(llGetAnimation(llGetOwner())); } } This script previously would print a mix of "Walking", "Running", and "Striding" while moving, and "Standing" if stuck against a wall. But now it also sometimes prints "Standing" while still moving normally

There have been long-standing issues with land leveling tools being left out on regions for too long, which causes performance problems that often require a region restart to resolve. While a restart is only a short-term solution, this has been a known issue for quite a number of years now. I believe it is time for Linden Lab to look into this again and implement a proper fix for a permanent resolution. It would be very much appreciated. Thank you, Mark

Both group chat and IM failing to initiate. I mostly experience it in Firestorm Social Island (simhost-0be97bd680c67540a.agni), as do the rest of the team. Starting an IM with someone else will work most of the time and every once in a while end up with a popup stating "Unable to start a new chat session with Username. The session initialization is timed out". Group chats will either fail silently or give the following message inline: "Second Life: You are the only participant in this IM session. Your message is not being broadcast at this ti2me." Tested on Second Life Release 26.1.1.23806384790, Alchemy Beta 7.1.9.2516 and Firestorm 7.2.3.80036.

URGENT SECURITY VULNERABILITY – UNAUTHORIZED EJECTS AND FALSE OBJECT ATTRIBUTION I am reporting what appears to be a serious security vulnerability in Second Life involving unauthorized parcel ejects. Residents are being forcibly ejected from parcels by users who do not appear to have the required land ownership, estate, or administrative permissions. This is not limited to a single incident or a single parcel. Multiple residents and lands appear to be affected. A particularly concerning aspect is that the system appears to attribute the action to an innocent object. When an eject occurs, the victim or nearby residents may see a local chat message such as: “The object 'Void - Demure Lashes (Avalon)' at Dearheart (196,46,2338) cannot teleport the parcel owner home.” The referenced object is a cosmetic attachment with no eject or teleport function. There is nothing in the object intended to eject, teleport, or remove users from the parcel. Nevertheless, the system displays the object as if it were involved in the action. This creates the appearance that a legitimate object caused the eject, while the actual source of the action appears to be something else. In one ongoing case, a resident has reportedly been ejected repeatedly, potentially dozens of times per day, across different locations. Entire groups of visitors on a parcel have also been forcibly ejected without authorization. We have already submitted multiple Abuse Reports and contacted Live Support, but the underlying issue remains unresolved. We urgently request that Linden Lab investigate this as a potential Second Life security vulnerability or exploit, rather than treating each incident as an individual land-management issue. Please review the server-side logs associated with the affected parcels and accounts, including: • The exact timestamps of the eject events • The account or system component actually triggering the eject • The permissions involved • The source of the eject request • Why an unrelated object is being displayed as responsible • Whether the same mechanism is being used across multiple regions and parcels If possible, please reproduce the behavior in a controlled environment and investigate how a resident without the appropriate permissions can cause another resident to be removed from a parcel. This issue is creating serious harassment and security concerns for residents and landowners. We need the technical/security team to identify the underlying cause, fix the vulnerability, and prevent unauthorized users from abusing this functionality. This report concerns a suspected platform-level security vulnerability, not a normal parcel eject performed by an authorized land manager.

Strange but repeatable behavior when an avatar cannot enter a parcel but a vehicle can. Avatar gets knocked off the vehicle and is left sitting in midair, unable to walk or stand.

We did 11 races in January with all together 96 racers and have about 7-12 racers per race. A race takes normally max 40min. But there was not a single race in January all sailors finished without disconnects or thrown off the sail boat on crossing sim boarders The region "Depace" is the worst sim in the last weeks. We crash there most of the times either on the crossing into Depace or out of Depace. It happens as well when someone sails alone there. There is not much underwater stuff that needs to be rezzed long. So there is no actual reason for these crashes there. Check the sim Depace first and seriously and don't just look at some general parameters or values. Do a serious check including server address changes and all those things. The other sims start getting the same issues more and more. So the whole area is worth to be seriously checked. and i talk about all these sims: Stodierski, Mautte, Paltiete, Mon Bayete, Degrand, Sarante, Petaccio, Rexach, Betacourt, Feraco, Repaci, Castrum, Palmerston, Rafeiraga, Valdivian, Couse, Gerache, Collhaytah, Port Pawtee, Maris, Conwy, Port Gonnornertnert, Quimadra, Depace, Lavaca, Val Encia, Benach, Coull, Oprince, Getachew, Wyrldmaker, Corpening, Geffers, Costagliola, Cottier

This is not a new bug, and I see lots of mention of it over the past many years on Community, but I don't see it here, so I'm putting it here. When a group member with "Ignore Landing Point" tries to teleport into a group deeded parcel with a landing point, they can't ignore the landing point, they get forced there first, before they can THEN teleport away elsewhere in the parcel

Bug reports on new double region crossing fixes by Pepper Linden