Report privately through GitHub's security advisories rather than in a public issue.

Please include what an attacker gains, the smallest input or sequence that shows it, and which package it is in. A failing test is the clearest report there is.

You should get an acknowledgement within a week. This is a small project without a security team, so a fix may take longer than that; you will be told where it stands rather than left waiting.

This is a rendering and game engine, so the interesting surface is the data it reads, not a network it does not open:

• Asset parsing — glTF, GLB, OBJ, STL and .f3d are read from files an application may not control. A malformed document must fail, not read out of bounds or allocate without limit.
• The writers on the other side of those decoders — F3dWriter, ObjWriter, StlWriter and GltfWriter all take a decoded document and produce bytes, and a document built from an untrusted import is exactly the input a writer sees next. The same rule applies: a document with an adversarial shape must fail the write, not read out of bounds or allocate without limit while producing one.
• The model editor's own project format, .f3dproj (writeProject/ readProject, the latter returning a sealed ProjectOpened or ProjectRefused) — a file a person can hand-edit or send to somebody else, the same trust level as a game's save file below.
• Level and save documents — JSON read from disk and from a game's own save file, which a player can edit.
• Shader bundles — loaded as assets, and the format is tied to the Flutter version that produced it.

• Anything requiring an attacker who already runs code in your process.
• Denial of service by asking the renderer to draw something enormous. A scene budget is an application's decision, and the engine takes what it is given.
• The demo applications' saved files being editable by their own player. A single-player game's save is the player's to edit.

Nothing is published to pub.dev yet, and there are no releases to back-port to: fixes land on main.