The vulnerability has been fixed, and existing applications should be patched urgently.
The vulnerability was discovered by a downstream project's bug bounty project, however, affects a common Meteor application configuration, particularly those using the attachSchema method from aldeed:collection2 aldeed:collection2-core, ongoworks:security or alanning:roles, that use allow or deny rules.
When the malicious WebSocket frame is evaluated against the developer-configured rules, it disables specific rules that would block the operation and thus allow execution.
This does not affect default Meteor configurations using Meteor's core packages, but becomes possible when commonly-used third-party packages listed above are also installed.
An application may be affected if it utilises a MongoDB collection's allow or deny methods to define collection-level rules and also uses any third party packages to enforce a schema on the same collection. This consideration applies whether the application uses the methods directly or the third-party manages the collection's rules on its behalf.
Only Mongo update operations for documents which a user was allowed to update are affected, but may permit updates to unexpected parts of that document. This becomes particularly relevant if an application has top-level properties to dictate a user's permission level, such as a field like "isAdmin".
The vulnerability has been fixed in the release of the allow-deny Meteor package version 1.0.9.
If you are not running Meteor 1.4, Meteor recommends you update now. Meteor versions prior to 1.4 use Node.js 0.10.x which is no longer supported by the Node foundation and may be subject to additional vulnerabilities.
If you are running Meteor 1.4 or later, Meteor recommends you update your application to use this package whether you believe your application is affected or not. You can do this by simply executing meteor update allow-deny. You should then verify it was successful by the command output, or through inspecting the .meteor/versions file.