First of all, there's all the standard web service security risks (connection security, authentication, authorization, session management, denial of service, logging, patching, etc.). I'm not going to talk more about those for now, but do bear in mind that you need a secure environment for something like this.
As for the risks specific to your system and ones like it... The most obvious risk comes if the users have any control over the filename the service creates. If so, you have risks such as file system traversal, overwriting of others' files, and so on. It doesn't look like you plan to do this, but it's something to bear in mind.
There's also the risk of uploading content that could be used to attack either the server or the other users. These attacks are easiest if the attacker can control the filename, but are possible if all they can control is the extension (and they learn the file name), and if there's a web API to download the file. To attack the server, upload a malicious file that the server will treat as executable (for example, a PHP page if the server supports those) and then navigate to it; this may not be possible if you're using a well-configured Node server. To attack other users, upload a malicious HTML file and try to trick other users into viewing it in their browser (resulting in stored XSS); this can be mitigated by making the files retrievable only from a different domain than the one for which the user has cookies / authentication, and/or forcing the browser to download the file rather than display it.
There's denial of service via simply uploading too much data. Consider how much data you'll allow users to store, and how you enforce that limit.
There's the risk of illegal content. The standard example here is child pornography; if users upload such content to your server and you are then found to be "in possession" of it, things could go badly for you. I'd recommend checking local laws, and ideally asking a lawyer, what your rights and responsibilities are when it comes to hosting user-uploaded content.
There's some risks to your JSON or base64 parsers, though these formats are simple and widely-implemented, so I wouldn't expect problems there. I don't understand why you want to use these formats, though; MIME content types are the standard way to upload files to a web server (and therefore feature built-in parsing in most web servers) and are less wasteful of bandwidth (base64 expands all encoded content to 4/3 the size, but there's no reason an HTTP request body needs to be composed only of printable characters).
Since you're storing a lot of user data, you need to consider at-rest data security. Encrypting the files individually, encrypting the whole volume, or using a transparently-encrypted external store are all potential ways to achieve this, but they also present the issue of key storage (as nearly all cryptosystems do). Don't forget to ensure your backups are also protected; tons of sensitive data has been leaked or stolen after somebody got ahold of the backup tapes or similar.
You may also want to consider the issue of user privacy. While not exactly a security feature, privacy (preventing unauthorized users - potentially including you, the service operator - from seeing what was uploaded) involves a similar mindset and is often provided using security tools (such as encryption). You tagged this question as "file-encryption", but you don't actually talk about encryption at all (base64 is an encoding, but there is no key involved; anybody who wants to can decode it, so it isn't an encryption scheme).
vulnerabilities
I mean any sort of unintended behavior, like file system tampering, malware injection and so on. – Karlom Oct 19 '18 at 9:53