I wouldn't consider this a major security issue as the values are limited to only your system's access to the third party sites. It is less desirable, but the values can be easily invalidated without any bleeding in to other systems that access the same services. It certainly doesn't hurt, and is even wise, to encrypt it, but you would have to encrypt it with a value found on the server anyway, so it only adds a mild amount of difficulty in gaining access to the keys. You can't hash them like you would a password since they are just a token value that has no relation to any user input you ever see.
Depending on your use case, you could use the user's password for your system to encrypt the values (if you aren't using oAuth for your system's authentication), and you could only grab and hold the tokens while the user is logged in (if using oAuth for authentication), but that limits things like your ability to do any interactions while the user is offline, which may not be a viable constraint in your system.
Use of those keys should be restricted to your applications access to the third party systems and may well be limited to just your server's access to those systems as well, depending on how things are setup.
They are of pretty low value to an attacker. It is a good idea to take what measures you can to protect them, but I wouldn't classify them as nearly as sensitive as a password (which is highly likely to be used elsewhere and gives direct access to the account).