[Potential Action Required] Update for HumanoidDescription APIs

Updates Announcements
1

Hi Creators,

To better protect your experiences from potential security vulnerabilities, we are updating the default behavior of two of our widely used APIs: Humanoid:ApplyDescription and Players:CreateHumanoidModelFromDescription.

The changes will go into effect 10/20/2025. For best development practices, if your experience is using either of these APIs and allows users to equip custom assets or non-avatar catalog items, action is needed to accommodate for the following changes.

What is changing?

The assetTypeVerification argument for the Humanoid:ApplyDescription and Players:CreateHumanoidModelFromDescription APIs defaults to Enum.AssetTypeVerification.ClientOnly. We will be changing this default value to be Enum.AssetTypeVerification.Always. This new default ensures that any assets loaded onto a humanoid are verified by the server, preventing the use of unapproved asset types.

Why are we making this change?

With the current default value, if your experience loads models with a HumanoidDescription by either calling Players:CreateHumanoidModelFromDescription or Humanoid:ApplyDescription on the server, there is no validation of the types of assets being applied (shirts, pants, accessories, etc). This could be a potential security vulnerability. Updating the default to always verify these assets on the server will eliminate this security risk.

Timeline

We want to swiftly enact this change while also giving an appropriate amount of time for developers to take action. This change will go into effect on Monday, October 20, 2025.

Does This Affect You?

  • You are NOT affected if: Your experience only uses these APIs to load standard avatar assets from the Roblox catalog (e.g., shirts, pants, accessories). No action is needed.

  • You ARE affected if: Your experience uses these APIs to load custom assets you’ve created or non-avatar catalog items. Action is required before Monday, October 20, 2025.

Action Needed

If you are loading non-avatar catalog items, you can choose one of the following courses of action depending on your experience:

  • If you can trust the assets being loaded in via Players:CreateHumanoidModelFromDescription or Humanoid:ApplyDescription, you can change all the calls to these functions in your experience to explicitly pass in Enum.AssetTypeVerification.ClientOnly.

  • If you can’t trust the assets being loaded in, then you should try to make your experience work with the new default value or pass in Enum.AssetTypeVerification.Always explicitly. This would forbid the loading of such assets via these APIs in your experience going forward.

Example of the Change:

-- Before
Humanoid:ApplyDescription(humanoidDescription)

-- After
Humanoid:ApplyDescription(humanoidDescription, Enum.AssetTypeVerification.ClientOnly)

Note: If your experience only focuses on loading in assets from the catalog rather than from the Creator Marketplace or your own custom models, then no action is needed.

Supporting Custom Use Cases

We know some creators use custom made or non avatar catalog assets; for example if you made assets for your own experience only. Therefore, we are keeping the Enum.AssetTypeVerification.ClientOnly option available. This allows you to maintain your unique vision while making a conscious choice about asset verification.

We’re committed to refining our APIs for the best possible security. Thank you for staying proactive with your code updates and aligning with best practices.

- Avatar Team

—
FAQs

What would happen if I change my default value, but I’m just loading avatar assets from the catalog?

  • Although no action is necessary if you are just loading avatar assets from the catalog, if you do change your default value, this will not impact your current experience.

Is there a way to mitigate the potential security risk, before the update goes live?

  • If your experience relies on loading non-avatar assets from outside the catalog, we recommend limiting what assets users can load into your experience by creating a whitelist of trusted assets for them to choose from.
  • If you are okay with your users only being able to load avatar catalog assets, we recommend you change all calls to these APIs to pass in Enum.AssetTypeVerification.Always. This can be done before the update goes live and will eliminate the security risk.

What assets can I trust?

  • Avatar catalog items (which undergo validation upon upload), items made by you, or items that you have personally verified.
71 Likes
2

This topic was automatically opened after 10 minutes.

3

This could be a potential security vulnerability. Updating the default to always verify these assets on the server will eliminate this security risk.

What are some examples of security vulnerabilities from this? I’m out of the loop

26 Likes
4

That is good. We will protect ourselves.

8 Likes
5

it’s probably about type validation as i get it

4 Likes
6

If you’ve been a member of /r/RobloxBans you may have seen a bunch of creators post about suddenly getting banned, with the ban reason being people wearing a specific white racist outfit.

An exploiter would join a game they want to get banned, inject their own HumanoidDescription, and since the default was that these assets were only ever verified to be allowed on the client -only-, the exploiter would fake-verify that racist outfit and join the game wearing it.

Said exploiter would then mass-report the place with bots, and when the AI analyzed your game it would see the fake Humanoid Description and assume you, the creator, allowed that humanoid description, thus breaking the Roblox Terms of Service.

Therefore, you would be banned for “breaking the Terms of Service” for creating that racist avatar, even though you had nothing to do with it.

This post is about Roblox changing the default Humanoid Description behavior to prevent exploiters injecting their own Humanoid Descriptions. The new behavior still allows exploiters to inject Humanoid Descriptions, but now it must come from Roblox-approved UGC or assets you specifically created, instead of just any asset someone could possibly find.

35 Likes
7

I assume this also impacts Humanoid:ApplyDescriptionReset? It is not mentioned in the post.
Edit: Just checked documentation, it does.

4 Likes
8

How does this impact AvatarEditorGames which use these methods simply as “buffers” to load items from the catalog.

In my game, which contains an avatar editor, I do not use any of these methods to apply accessories to the Player’s character but rather as a way for me to load that accessory and apply manually it myself.

3 Likes
9

How does this affect usage of this API within Studio, I’m currently theory crafting a feature in Dropper that allows you to build a rig using custom assets within your game, alongside the catalog ones.

2 Likes
10

If the item is from the catalog, then it shouldn’t impact that at all. Regardless of the verification type being Always or ClientOnly, you should get the same result.

4 Likes
11

If this is something you are calling during Studio Edit time, I don’t believe anything changes. If you are calling it on the server during Studio Play, the same advice from above applies for your use case. You will need to pass in Enum.AssetTypeVerification.ClientOnly specifically when calling these APIs.

3 Likes
12

Correct, this would also apply to Humanoid:ApplyDescriptionReset

3 Likes
13

A very interesting set of exploits for sure

Can I DM you relating to this thread? I’d like to know if it fixes a set of vulnerabilities that have been affecting a game I’ve been helping out.

5 Likes
14

This makes no sense at all. If the HumanoidDescription is purely client-side and created by the exploiter there should have been no way it could affect moderation. This sounds like an engine vulnerability Roblox should be addressing directly instead of inconveniencing developers with a bandaid fix.

2 Likes
16

I just noticed this event was added; part of this update?

image
image957Ă—189 5.85 KB

2 Likes
17

This is unrelated to the update. The ApplyDescriptionFinished event was added as part of an update from last year: https://devforum.roblox.com/t/upgraded-humanoiddescription-api/3105552

3 Likes
18

This is fairly confusing, how/why is this needed for Asset moderation? Seems like there could’ve been several other ways of implementing this. This doesn’t make my Asset loading any harder to implement, but it certainly doesn’t seem very well thought out update. If anything it causes me concern as I don’t want my players getting moderated accidentally.
Could we potentially get methods to load from the catalog separate from these methods now?

2 Likes
19

Surprised this wasn’t done yet.

For anyone confused, this should only affect you if you’ve uploaded an avatar item as a Model asset and are using the Model ID in a HumanoidDescription. Just set the AssetTypeVerification to ClientOnly to continue allowing these assets to be loaded by calling ApplyDescription on the server. (Inserting models by calling ApplyDescription on the client was never supported.)

5 Likes
20

Any plans to allow these methods to respect the EnableDynamicHeads property? I use them in my game to load players avatars but It forces facial animations on the characters which I don’t want

1 Like
21

this isn’t about asset moderation… maybe internal (your own hired mods) asset moderation, but it clearly says the reason is: there is no validation of the types of assets being applied (shirts, pants, accessories, etc). This could be a potential security vulnerability.

1 Like