There are a few attack vectors to consider here, not just those with the intended effect (some malicious player wants to boost their stats) but also other effects as well.
As the other answers have eloquently put, never unquestioningly trust the client. Because there is no way to tell on the Internet what has happened to your client (if there is a bug in the client or the network, if the client has been modded, or even if it is your client at all), a server must always sanitize a client's inputs, making sure they are plausible and correct, before using them. There are several aspects to this:
Keep the network out of it: As much as possible, encrypt all of your network communications using SSL certificates and individual symmetric keys for each client. That way, when you receive messages from a client, you can at least know that they are unequivocally that client and that their messages have not been compromised by the network. (You still can't usually trust the client, though, but it is easier if they can trust you.)
Make sure that the API you provide to clients is exactly and only what they need: For instance, do not provide a call on the data server that updates a character's stats directly. Instead, provide simple, normal game actions to the client, and allow the server to calculate when stat changes should happen.
Make sure that the calls to your server/receiving client APIs make sense: You should first make sure that a message received from a packet corresponds to a client API call at all (and thus have a data format that allows you to verify this), then make sure that the arguments provided make sense and that it makes sense for the client to make this call at this time. For instance, a player who doesn't have a shotgun should not be sending calls to fire one. (NOTE: Many higher level netcode APIs in consumer game engines like Unity and Unreal will check if incoming messages match one of your expected message types, but will not check the contents for you.)
Enforce all prerequisites: In general, if any part of your code ever makes any assumption about the arguments, you should already be enforcing those assumptions with assertions, which will safely terminate your program if they are not met. Whenever you receive any network messages, you are guaranteed very little about their contents, so at that point you should ensure that the network message meets all of the assertions in all of the code in which it will be used (which is probably your entire code base).
Beware of DoS attacks: If a rogue client can't get their way, they can just take the server down with them and ruin it for everybody else by simply overwhelming the server with faulty packets. You can never perfectly safeguard against this, but you can increase your tolerance for it by simply refusing to honor requests that are sent from the same client too frequently.
Secure your server in other ways, too: Keep in mind that there are other ways to access your game server for administrative purposes - for instance, you might use SSH or Remote Desktop to log into it and fix things, or it may contact a data service. Be sure that those channels are secure, too, because an attacker may attempt to compromise your server by going through one of these backdoors.
If all else fails, keep good backups and logs and allow user reporting: If you cannot prevent a rogue action, a good backup will allow you to roll it back with little to no collateral damage. Also allow players to report the condition, and you can read the server's logs to investigate what happened, find the cheater, and act accordingly. (Be sure to keep your reporting system secure, too!)